An unwanted redirection happens on the host server if I browsed for https it redirects me to HTTP and notices that I haven't any redirection rule to HTTP. the odd thing is that I can browse my app in https from any other device it works well, but not from the host itself. Another thing to notice is that I can bind the site to any other https port and it works well from anywhere, but I want to use the default https port.
I'm using IIS 8.
so any help on this issue?!
Some browsers are caching redirects. You need to clear your browser's cache and try again
Related
I set up a "Redirect to SSL" on port 80 for Domino server. When I first open browser, http requests on other ports are cool, stay http. But after I hit 80 for the first time and the browser redirects to https, all other ports are redirected to https and throw 404. The port is ignored.
When clearing browse history, everything is restored until the first redirect on 80 and the above is repeated.
The default tcp/ip port is 80 so that's not explicitly specified in the url addy box, so that's probably why the browser throws a wet blanket over all the explicit ports. It's caching on the base url...?...
I've read about 301 redirects, etc. and how it's sort of a headache. Is there something I can do about this? The only recourse I see is to dump the server redirect and code an onLoad on all 80 sites which checks protocol, if http, location.href change to https. Then ask user to bookmark new https addy. This seems to not cache the redirect. Thank you very much for any help.
I set everything well and some https request did be proxied well, but some are still unknown , is there any new way I don't known to prevent being proxied ?
I found that the https connections checked the cert on apps their own. Which means you can't just add the cert to your device's system and hope it works.
There are more works should be done to capture these data by using proxy.
More detailed things are you have to hack the app to capture. For those information just google "JustTrustMe".
We have a site that we are trying to configure as a client in a SSO scenario, using WS Federation and SAML.
Our site sits behind a load balancer that is doing SSL offloading - the connection to the balancer is under https, but decrypted and forwarded (internally) to the actual site under http and port 81.
Somewhere the WS federation module is attempting to redirect us, but is building up the URL based on the port and incoming protocol to the website:
We request:
https://www.contoso.com/application
and are getting redirected to:
http://www.contoso.com:81/Application
Which doesn't work as the load balancer (correctly) won't respond on this port.
And it seems to be related to the casing of the virtual directory. Browsing to
https://www.contoso.com/Application
seems to work without issue.
(Note for completeness, attempting to browse to http://www.contoso.com/Application with no port will correctly redirect us to the SSL secured URL).
I am trying to find out:
a) Where this redirect is happening in the pipeline and
b) How to configure it to use the correct external address.
If anybody is able to point me in the right direction, I would very much appreciate it.
EDIT 14:19: Seems to be either the WsFederationAuthenticationModule or the SessionAuthenticationModule. These do a case sensitive comparison of the incoming url to what it expects and redirects otherwise:
https://brockallen.com/2013/02/08/beware-wif-session-authentication-module-sam-redirects-and-webapi-services-in-the-same-application/
So that seems to be happening, its a matter now of trying to get the site to behave nicely and redirect to the correct external url.
The following seems to be related and ultimately points to the culprit in the default CookieHandler:
Windows Identity Foundation and Port Forwarding
Looking at that code decompiled in VS, it compares HttpContext.Current.Request.Url against the targetUrl and will redirect to the expected 'cased' version otherwise (in our case including the errant port number).
It would seem that explicitly setting the path attribute of the cookie fixes this issue. Either an empty string or the virtual directory name seems to work:
<federationConfiguration>
<cookieHandler requireSsl="true" name="ContosoAuth" path="/Application/"/>
<wsFederation passiveRedirectEnabled="true" issuer="https://adfsSite" realm="https://www.contoso.com/Application/" reply="https://www.contoso.com/Application/Home" requireHttps="true"/>
</federationConfiguration>
So I have spinnaker running behind an https load balancer and my external ports use the standard 443 which get port mapped to the spinnaker instance still on port 9000. I've gotten pretty much everything to work except a redirect from gate is still appending the :9000 port to my URL.
requests sent to https://my.url.com/gate/auth/redirect?to=https://my.url.com/#/infrastructure send back a redirect response with the location header in the 301 location:https://my.url.com:9000/gate/login which fails because the load balancer is only listening for 443. If I manually delete the port and go right to https://my.url.com/gate/login the oauth flow works as expected and once authed all deck functionality and subsequent gate queries work as expected.
In my /etc/default/spinnaker file I have
SPINNAKER_DECK_BASEURL=https://my.url.com
SPINNAKER_GATE_BASEURL=https://my.url.com/gate
in /opt/spinnaker/config/gate-googleOAuth.yml I have
spring:
oauth2:
client:
preEstablishedRedirectUri: ${SPINNAKER_GATE_BASEURL}/login
useCurrentUri: false
and I've ran /opt/spinnaker/bin/reconfigure_spinnaker.sh plus restarts to make sure deck and gate get updated. Does anyone have any ideas what I might be missing?
I figured out my problem. With the help of this issue pointing me in the right direction (https://github.com/spinnaker/spinnaker/issues/1112) and some digging I found that the issue was with apache2 and the reverse proxy back to gate.
ProxyPassReverse
This directive lets Apache httpd adjust the URL in the Location, Content-Location
and URI headers on HTTP redirect responses. This is essential when Apache httpd
is used as a reverse proxy (or gateway) to avoid bypassing the reverse proxy because
of HTTP redirects on the backend servers which stay behind the reverse proxy.
from apache2 documentation https://httpd.apache.org/docs/current/mod/mod_proxy.html#proxypassreverse
I am running a Mojolicious app on Hypnotoad. It is listening to port 443 and it can be accessed through https.
how can I forward all HTTP request to HTTPS?
According to this post your server listen only 443 port. So you should add another application to handle 80 port.
The best way to add nginx or apache in front of hypnotoad and do it there (redirect, rewrite).
But if you don't want to have nginx, you may write Mojolicious application
which listen two ports and have hook before_dispatch wich handle all requests and make redirect changing only scheme.
If you want i may to attempt to write such minimal example.
Upd. I decide to add example
You can't, at least not directly. While you could use iptables or similar to forward port 80 to 443, in practice that wouldn't work because the browser doesn't expect to have to do an SSL handshake for a plain HTTP URI. You have to run a trivial web app on port 80 (probably with a separate Hypnotoad or similar) that answers every request with a redirect to HTTPS -- probably either to some login page or to the same URI as requested with just the scheme changed.