I'm trying to redirect traffic from all services through an API Gateway. To be backward compatible I try to define a CNAME to redirect traffic to the API Gateway. As a result, I have a request coming to the subdomain of my API Gateway but with the Host header set to my service subdomain. Something like this: curl "https://gateway.example.com" -H "Host: myservice.example.com" Since the domain the and the Host are different, Cloudflare (proxied DNS) return 403 HTTP error, hinders the request from reaching the gateway.
Is there any way to relax this restriction while using Cloudflare proxy?
Did you have a look at the Origin Rules feature? One of the capabilities included allows to override the Host header of the incoming proxied request. You could use this to set the correct Host header your origin infrastructure is expecting based on the characteristic of the incoming request.
Related
In case I use an apache proxy server for my ASP Net Core 2.2 app, what actually happens when I use app. UseHsTs();?
UseHsts adds a header Strict-Transport-Security to the response. When the site was accessed using HTTPS then the browser notes it down and future request using HTTP will be redirected to HTTPS. So, accessing the site using HTTPS at least once is mandatory to make this work.
Also the expiration time set by the Strict-Transport-Security header elapses, the next attempt to load the site via HTTP won't be automatically redirected to HTTPS.
Note UseHsts excludes the following loopback hosts:
localhost : The IPv4 loopback address.
127.0.0.1 : The IPv4 loopback address.
[::1] : The IPv6 loopback address.
You could refer to the MS documentation on HTTP Strict Transport Security Protocol (HSTS) for more details.
I have a URL (A) which responds with a cached resource and status code 304.
In Cloudflare, I've setup a forwarding URL page rule (temporary redirect) to forward A to the new URL (B). Unfortunately, this is not working. Is it possible that the 304 response is taking precedence?
Some additional notes:
Cloudflare Browser Cache Expiration setting is set to "Respect Existing Headers"
Cloudflare caching level is set to "Standard"
URL A and B are both on the same subdomain and the HTTP proxy is turned on
Set the HTTP Proxy on the DNS setting and be patient.
We run a website which is hosted using WCF.
The website is hosted on: https://foo.com and the ssl certicate is registered using the following command:
netsh http add sslcert hostnameport=foo.com:443
When we browse the website on the server, all is fine, and the certificate is valid.
There is a loadbalance in front of the server which listens to bar.com and then redirects the request to our server.
The loadbalancer doesn't rewrite the get URL, but only the Host Header.
The rewritten header looks like this:
GET https://foo.com/ HTTP/1.1
Host: bar.com
Connection: keep-alive
Now we have some issues which indicates that the ssl certificate is invalid in this case.
The Loadbalancer itself has a certificate registered listening to https://bar.com
Questions:
Is it ok/allowed that the get URL and the Host in the http header are different?
If it is ok to have different values in the header, under which url should we run the site? get URL or Host url?
Well, referencing the RFC2616:
If Request-URI is an absolute URI, the host is part of the
Request-URI. Any Host header field value in the request MUST be
ignored.
So, back to your questions:
It is allowed but a bad idea as it will create confusion, better to use relative path. i.e.
GET /path HTTP/1.1
instead of
GET https://foo.com/path HTTP/1.1.
Modify the loadbalance configuration to do so. Or make the both values the same.
If Host header has a value different than the request URI, then the URI is taking priority over the Hosts header.
I've setup the standard GCP load balancer to point to my instance group. It talks over the same port on the instance. I would like to redirect http to https. I would normally do this in nginx or apache on the instance but that won't work since its https already from the load balancer.
Is there a way to rewrite the url similar to if I was using nginx and apache to load balance in GCP's Load Balancer? or should I forward http and https to the instance and have the instance handle the rewrite as I normally would. I'm new to GCP thanks in advance.
You can set it up the same way as Nginx does. When you see traffic on a port which is not https, you redirect it to HTTPs.
To do this, you can use X-Forwarded-Proto header which contains the protocol using which the traffic came in. On your server, you can simply look for traffic that has http header and upgrade that request to HTTPS.
Most commonly used way is to use 301 redirect, but that is not a great practice. One should use HTTP 426 upgrade request header.
Read more: Is HTTP status code 426 Upgrade Required only meant signal an upgrade to a secure channel is required?
RFC doc: https://www.rfc-editor.org/rfc/rfc2616#section-14.42
There's probably an answer already on stackoverflow that I'm missing, sorry in advance for that, I just can't find it.
I have a small TCP server running on my localhost that, for security reasons, will not support CORS.
My question is, if CORS is for cross-domain protection, why is it being requested when I have a page on http://localhost/ request a connection to http://localhost:xxxx
I know I can turn off the security in my browser, but Im trying to understand why localhost to localhost connections are being treated as cross-origin.
XMLHttpRequest cannot load http://localhost:8000/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:63342' is therefore not allowed access. The response had HTTP status code 500.
Because localhost (port 80) is a different host than localhost:8000.
See RFC 6454, Section 5:
If the two origins are scheme/host/port triples, the two origins
are the same if, and only if, they have identical schemes, hosts,
and ports.
Same-origin Policy
The same-origin policy permits scripts running in a browser to only make requests to pages on the same domain. This means that requests must have the same URI scheme, hostname, and port number. This post on the Mozilla Developer Network clearly defines the definition of an origin and when requests result in failure. If you send a request from http://www.example.com/, the following types of requests result in failure.
https://www.example.com/ – Different protocol (or URI scheme).
http://www.example.com:8080/myUrl – Different port (since HTTP requests run on port 80 by default).
http://www.myotherexample.com/ – Different domain.
http://example.com/ – Treated as a different domain as it requires the exact match (Notice there is no www.).
For more information refer to this link