I'm trying to implement URL redirects from http to https as described by [https://cloud.google.com/load-balancing/docs/https/setting-up-traffic-management][1] but I'm getting ERR_TOO_MANY_REDIRECTS
I have a storage bucket with a very simple HTML page.
I have an external HTTP load balancer in front of it. Static IP address. SSL cert. I managed to connect everything so that both http and https requests for the site load the contents of the bucket.
I tried to add the HTTP redirect as per the document:
Changes 'Host and path rules' from 'Simple' to 'Advanced...'.
The default route still points to the bucket
I added a new route. Host is 'www.example.com. The default path rule points to the bucket. The second path rule matches /* and does a prefix/HTTPS redirect as described in the above link.
Once the config is saved, either http or https requests to www.example.com results in ERR_TOO_MANY_REDIRECTS
What am I doing wrong? Really appreciate any help you can provide.
[Backend configuration][2]
[Frontend configuration][3]
[Host and path rules][4]
[Redirect path rule][5]
[1]: https://cloud.google.com/load-balancing/docs/https/setting-up-traffic-management
[2]: https://i.stack.imgur.com/lkhUF.png
[3]: https://i.stack.imgur.com/FYst0.png
[4]: https://i.stack.imgur.com/zsTOX.png
[5]: https://i.stack.imgur.com/2tEDE.png
FYI - someone in Google Groups pointed out that I needed 2 load balancers. 1 to terminate the HTTPS traffic and the second to redirect the HTTP traffic. Works like a charm.
Related
I have a ALB set up behind a cloudfront distro. I have a rule to redirect an HTTP request to URL A to URL B which is not on AWS infrastructure.
When I query the ALB directly for URL A, the load balancer properly redirects to URL B. When I query a cloudfront endpoint for URL A, I get a 403 error back. Per the troubleshoot 403s aws doc, it seems the issue is that I don't have an alternate CNAME configured for URL B. However, since it's not on my SAN certificate that's associated with my CloudFront distro, I can't add it to the list of alternate CNAMES. is there a workaround to allow requests to URL A to properly travel through my cloudfront distro and get redirected? It doesn't make sense to me that I can't do this for an HTTP request.
verified that the ALB can be queried directly and redirect works
tried to add an alternate cname for http domain
removed wacl on alb to make sure that wasn't blocking it
I have installed keycloak using helm.
A Traefik ingress is created to allow access from public
After the admin password is created from localhost:8080, i am able to login into admin console only when i am port forwarded and local access.
When i use the public url and click on admin console, it redirects to https://website/auth/admin/master/console/ and shows a blank page.
I found the problem but when i change the servicePort: https inside ingress, i get an internal server error
status code 500.
when i use http port,i get these errors:
Mixed Content: The page at 'https://url/auth/admin/master/console/' was loaded over HTTPS, but requested an insecure script 'http://url/auth/js/keycloak.js?version=mxda6'. This request has been blocked; the content must be served over HTTPS.
Mixed Content: The page at 'https://url.ca/auth/admin/master/console/' was loaded over HTTPS, but requested an insecure script 'http://url/auth/js/keycloak.js?version=mxda6'. This request has been blocked; the content must be served over HTTPS.
i looked through traefik logs:
level=debug msg="'500 Internal Server Error' caused by: x509: cannot validate certificate for x.x.x.x because it doesn't contain any IP SANs"
I found a fix but it still doesn't answer my question why when ingress points to https, it doesnt work. Is there an answer?
So the fix is to add this under ENV in the statefulset keycloak deployment.
In the ingress, the service port is http
- name: PROXY_ADDRESS_FORWARDING
value: "true"
i found it at https://github.com/eclipse/che/issues/9429
I had the same issue. The white screen isn't helpful, but the browser console is. It is blocking mixed content, namely the script http://url/auth/js/keycloak.js?version=mxda6.
The documentation on Docker Hub says:
Specify frontend base URL
To set a fixed base URL for frontend requests use the following environment value (this is highly recommended in production):
KEYCLOAK_FRONTEND_URL: Specify base URL for Keycloak (optional, default is retrieved from request)
I provided the external url with https scheme in my manifest and the script in question is now appearing in the index.html as https url.
- name: KEYCLOAK_FRONTEND_URL
value: "https://url/auth"
Since it is "highly recommended" I suppose there are more slight problems without this variable set, like other links being generated wrong, e.g. in emails though I didn't check that yet.
So I'm trying to figure out if this is something I can configure through my DNS host or if I need to set this up on my app server.
My situation
I have a heroku app and domain name (lets say example.com) which is set up for https on both www and root/apex. So https://example.com and https://www.example.com both work. I am also able to redirect any http requests (both www or root/apex) to domain to the https equivalent so in other words:
http://www. redirects to https://www. and http://root redirect to https://root.
My issue
I want all combinations of my urls (http or https and www or root) to direct to a single url (https://www or https://root). My aim is to just have consistency in the urls. I noticed that most redirects work EXCEPT when trying to redirect from https://example.com to anything else.
What is the DNS host approach for this? And if it's not possible from DNS host the normal approach?
DNS provides translation from the domain name in a URL to an IP address that the client can contact. If your problem involves anything else whatsoever in the URL, it's not a problem DNS can solve.
The problem you describe involves the difference between HTTP and HTTPS. This is not part of the domain name in the URL. Therefore, DNS is not your problem.
When I was on AWS, setting up a 301 redirect for my website from www.example.com --> example.com involved simply creating a S3 bucket as a static website and set it up to redirect all traffic to example.com.
I don't see this option on Google cloud storage and I can't think of any way to do this with the HTTP load balancer.
Is the only way doing it involves patching my backend to notice addresses that start with www and strip the www and redirect ?
Google has a way of using buckets as backends for the http load balancer.
It is still in alpha but you can read about it and ask them to try it here. Use it with a html file to redirect like suggested here and my guess it should work.
Alternatively, I use Cloudflares free service, which allows for 3 free redirects. Saving you the trouble of configuring redirects in your backend. This can be done with some other CDN services as well I don't know which.
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