Within qqq.domain.fr, I want to be able to display an iframe of domain.fr/calepin/etc
I thought setting the header_down on the reverse_proxy would do the trick but even though I DO get the SAMEORIGIN in the response header when I access domain.fr/calepin/etc directly, I get DENYed when accessing it through the iframe.
4. Error messages and/or full log output:
From the iframe GET response : x-frame-options: DENY
If I accessed directly the response has : x-frame-options: SAMEORIGIN
5. What I already tried:
Adding X-Frame-Options "SAMEORIGIN" as default for domain.fr, adding it as header_up for the proxy, …
The service behind the proxy is using docker and I don’t know nor want to change its config if the problem comes from that. Why wouldn’t the header_down rewrite this option in all cases??
FYI, you can use handle_path instead of route here, and it’ll save you from needing uri strip_prefix, because handle_path does the stripping implicitly.
I think the issue you’re having though is that try_files executes before your route. This is because of Caddy’s default directive order:
I’d instead write your config like this, which may fix the problem:
Using handle and handle_path ensures that these two routes are handled mutually exclusively, so try_files won’t happen when you’re trying to proxy, and anything not /calepin/* will be handled by your file server.
I also changed your header_down to header which I think is more correct here.
In short, I shouldn’t put anything special in my qqq.domain.fr block, and just needs to set the xframeoptions as I did in the /calepin route, except with a bullshit name that will make it ignored by the browser.
I’ll try to find out how to remove this header instead in the header_down, as setting even an empty string makes the browser output some error log. Also I would prefer to limit the inclusion of this in an iframe only when coming from qqq.domain.fr . If you have any idea?
You can remove headers by putting - before the header name, like this:
header_down -X-Frame-Options
Just for kicks, can you try using the header directive instead? I think it should work just the same (with one less line) but I just want to confirm. Just put this before your reverse_proxy line:
header -X-Frame-Options
Also FWIW I still recommend wrapping your config with handle_path and handle, because it’s quite inefficient to have Caddy run try_files on requests where you know it never makes sense (i.e. /calepin/*), since it will do multiple filesystem calls.
I tried using the header directive indeed but it can get overwritten by the proxied service I think. I guess it would work in all cases if I put it after the reverse_proxy block but I didn’t try that.
I didn’t have time earlier to follow your advice about handle_path but I’ll be doing that now! Thanks for the tip!
Do you have an idea how to allow the iframe to work only from my subdomain? What I have in mind is to add a content-security-policy with frame-src at the same place I remove the x-frame-options.
Right - I guess you would need to use defer, like this, so that header happens after the proxy:
header -X-Frame-Options {
defer
}
So I guess you lose out on the terseness benefit there
Frankly, I don’t. I haven’t done the deep dive on security headers and all their edgecases yet. I don’t typically build things that require deviating from defaults.
1/ This defer option helped me do something else which is nice!
2/ On my instance the handle_path isn’t recognised as a directive, it might be a different version but I don’t see the minimum required version in the docs for that directive.
3/ Also something really weird after more testing: if I let the X-Frame-Options directive in the caddy_security header, then any subsequent header definition of that same header is ignored, whether in a header or header_down. Why would that be?
Oh, yeah you’re using a very old version. Please upgrade to v2.3.0
I think you misunderstand how the Caddyfile works - as I linked to earlier, directives are sorted according to a predetermined list, so the position inside your Caddyfile does not affect behaviour. The exception is route which allows you to override the order, but route blocks themselves will be ordered at the top level according to the list.
This means your “early” and “late” headers will happen at the same time.
Also import is basically just copy-paste so directives in there will also be subject to the Caddyfile directive sorting.
Oh indeed I will fix my installation! I think I installed it manually at the time and the v2 was new and shiny.
I thought the order of entry would impact the order of precedence… So how am I supposed to have a default header and set another one on a case by case basis?
In this case as they are all the same header directives, how is it sorted? Thanks for the info!
I think in this case, they’ll be grouped up together but in the order they appear in the Caddyfile. You can find out but running caddy adapt --pretty on your config to see the underlying JSON for you config.