You can replace this with header_up Host {upstream_hostport} which avoids needing to repeat the domain twice.
You don’t need this, Caddy already passes through the original domain as X-Forwarded-Host.
This is not useful information. Better to use X-Forwarded-Proto which Caddy already sets by default (which will always be https in your case anyway).
header is not valid inside of reverse_proxy. You have to use header_up to set headers on the upstream request.
The way I would do it is by setting vars using matchers, and then set the header using that variable.
@educrag host educrag.com
vars @educrag origin "https://educrag.com"
vars origin "https://{host}"
reverse_proxy ... {
...
header_up Origin {vars.origin}
}
That said, I’m not sure I understand what you’re trying to do, because the “pseudocode” you have there is essentially tautological. If the host is educrag.com then setting Origin to that value is the same as setting Origin to the host.
I’m confused by the way you worded things, sorry. Probably a language barrier issue. I’ll try to reply as I can but you might need to try again and clarify what you mean.
Why not just use X-Forwarded-Host in your app instead? It’s already available for you, no need to add a new custom header.
I’m not sure what you mean by this.
This sounds like a bug in your application, then. It be reading from X-Forwarded-Host to get the original domain name.
But maybe I’m not following the “flow” you’re talking about.
I have a website educrag.com, and i am using a reverse proxy from caddy to help manage incoming traffic for multiple domains. When someone tries to access my site through the reverse proxy’s domain (let’s call it dynamo.com), there’s an issue: the login process doesn’t work because the cookies needed for logging in are only set up for educrag.com.
If its logged in with other domain it throws an error in browser, so it just loops in the login screen.
How to handle this in caddy without touching the Main configuration in server.
In server this is the configuration which we cant change.
Certainly! Its privacy guidelines for our application. We need to ensure that the completion of this reverse proxy project aligns with our privacy standards. Therefore, is there an alternative way to solve this issue using the Caddy configuration without violating our privacy guidelines?
If i remove that there are some clients who will move away from us thats the reason.
All you need to do is change your application to check that incoming requests come from a trusted proxy (i.e. Caddy) by checking that the remote IP address is from a trusted list (e.g. private IP ranges), and if so you can trust that X-Forwarded-Host was not tampered with. Then you can use that header’s value in your cookie logic.
To clarify, I’m saying that your app should trust Caddy’s IP address, meaning that the IP address of the server you run Caddy on (or the range of IPs if you have many) should be added to your app’s config.
All you need to do is check the remote IP address on all incoming connections, and if it matches, then you know the request is coming from a trusted server.
Set that in whatever context in your app, and use that condition to decide whether to use X-Forwarded-Host or not.
Or you could just reject all incoming requests not coming from Caddy (respond with an error) if you want to make sure all requests go through Caddy.
That’s where the problem arrives, Many external sites need to access our APP via API like Stripe, Lambda, and GCP cloud functions, etc. In that case, those triggers will be blocked if I restrict them via IP.
I am running Caddy in an NLB that only has a DNS name in common. We can’t set IP restrictions because it runs via an auto-scaling group, so the IPs are dynamic. Even so, how can I capture the remote IP address, which cannot be manipulated via a reverse proxy, in order to whitelist it in the app?
A different approach, you could set a header with a secret value that you can check in your app to confirm the request came from Caddy and nowhere else.
