How do I set up another Host Header in the cloudflare worker?
For example, I have set up a 1.2.3.4 ip for my site's www record
By default www requests are sent with the header www.ex.com but I want to send the www requests with the new.ex.com header
You need to configure a DNS record for new.ex.com so that it points to the same IP address. Then, you can make a fetch() request with new.ex.com in the URL.
If you cannot make new.ex.com point at the right IP, another alternative is to make a fetch() request using the resolveOverride option to specify a different hostname's IP address to use:
fetch("https://new.ex.com", {cf: {resolveOverride: "www.ex.com"}});
Note that this only works if both hostnames involved are under your zone. Documentation about resolveOverride can be found here.
You cannot directly set the Host header because doing so could allow bypassing of security settings when making requests to third-party servers that also use Cloudflare.
// Parse the URL.
let url = new URL(request.url)
// Change the hostname.
url.hostname = "check-server.example.com"
// Construct a new request
request = new Request(url, request)
Note that this will affect the Host header seen by the origin
(it'll be check-server.example.com). Sometimes people want the Host header to remain the same.
// Tell Cloudflare to connect to `check-server.example.com`
// instead of the hostname specified in the URL.
request = new Request(request,
{cf: {resolveOverride: "check-server.example.com"}})
Related
I was assign a task by my direct manager to make sure that all the websites in the company will have "X-Forwarded-For" HTTP Header set, in order to receive the original IP of the users for our Web Application Firewall logs.
I am not a developers, but I need to make sure our developers do that, and they seem to not understand what needs to be in the value of the header.
Because looking at some examples, it seemed that some people put specific IP like this:
X-Forwarded-For: <client>, <proxy1>, <proxy2>
which doesn't make any sense to me, because how can u type the IP in the value when it is completely random for each one?
Basically, I need that our logs will contain the real IP from each computer which surf behind a proxy or a load balancer.
Would like for some help : )
Thanks!
If you have one reverse proxy (or load balancer) between the client and the application server, then the proxy should add the header:
X-Forwarded-For: <client>
before forwarding the request on to the application server. The application server receives the request from the proxy IP but can deduce the client's IP from the value of the header.
If you have two reverse proxies (or load balancers) between the client and the application server, the first proxy (the one nearest the client) acts the same as above.
The second proxy receives the request from proxy1's IP and also receives the X-Forwarded-For header from proxy1. It then appends the IP address from where the request was receives (proxy1) and passes the updated header to the application server as:
X-Forwarded-For: <client>, <proxy1>
Each proxy or load balancer is responsible for creating the header if it does not already exist, and appending the IP address of the from where the request was received (i.e. the previous step in the chain).
Only the first IP address is necessary to identify the client, the remaining IP addresses are necessary to ensure that the header has not been faked.
Ultimately my goal is to be able to load my PMS admin interface via Organizr. I had already tried simply using the URL https://app.plex.tv/desktop through Organizr, but that URL disallows loading the page in iFrames, so now I'm trying to use Caddy server to reverse proxy it to my local LAN IP instead ...
I have this code in my Caddyfile (note that my PMS is hosted on a different pc on my LAN):
proxy /pms https://192.168.234.234:32400 {
websocket
keepalive 12
header_upstream Host {host}
header_upstream X-Real-IP {remote}
header_upstream X-Forwarded-For {remote}
header_upstream X-Forwarded-Proto {scheme}
transparent
}
Then when I try to visit the URL, it gives me a 502 Bad Gateway, and the Caddy log file says [ERROR 502 /pms] x509: cannot validate certificate for 192.168.234.234 because it doesn't contain any IP SANs
If I add the insecure_skip_verify directive, I get the error: 401 Unauthorized instead.
I'm still pretty new to using Caddy, anyone know what's going on here?
Since you use Caddy which will deal with the SSL, redirect to http instead of https.
To solve my particular problem; in Organizer I used the Plex web URL instead.
https://192.168.234.234:32400/web
Note the /web at the end.
Another option, was to have Organizr open it using the PopOut option, which just acts something like a regular bookmark, and loads any URL in a new tab, and/or add a line to the Caddyfile like this:
redir /pms https://app.plex.tv/desktop 301
Then in Organizr you could use either the /pms URL, or the direct Plex URL https://app.plex.tv/desktop, and it'd just load Plex in a new tab.
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.
My setup is as follows:
client -> proxy(dnsname eg. https://test.com) -> Jetty webapp(1.2.3.4)
The webapp sends a redirect response back (to an authentication webapp) to the client. It automatically points to the proxy via dnsname eg. https://proxy/auth and cannot be configured further.
The issue with this is the webapp will pass redirects back to the client and the client cannot resolve https://proxy as I can't make it a dns entry. Is it then possible for the proxy to intercept the traffic from the webapp (https://proxy) and change it to https://test.com? Even better can the proxy autodetect the entry dns name and append it to any responses from the webapp?
I'd envisioned the following:
client request https://test.com/page1-> hits proxy which resolves to webapp -> webapp gives redirect response via https://proxy/auth -> proxy intercepts and changes redirect to https://test.com/auth
I need this so that everything behind the proxy isn't machine nor ip specific. I can shift and deploy to any environment.
I figured this out eventually. You can just modify the redirect headers in the location field.
Header edit Location "(^http[s]?://proxy)" "https://whatevernameyouwant"
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.