Ok, I’ve tried the configuration, and the header
part is set correctly, but the issue is still only partially solved. There is still the issue on how to emulate the internal
of Nginx, currently the redirect does not work and the file can be freely retrieved from GET
. The relevant console log is in this original github issue.
Here is the relevant Nginx configuration taken from the official documentation:
location /_protected {
internal;
alias /path/to/back/media/;
add_header Content-disposition "attachment";
}
location /media {
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Scheme $scheme;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://127.0.0.1:8003/;
proxy_redirect off;
}
And the current Caddyfile section:
handle_path /_protected/* {
header +Content-disposition "attachment"
file_server {
root /path/to/back/media
}
}
handle_path /media/* {
reverse_proxy localhost:8003
}
I believe this is only an issue with X-Accel-Redirect
. As you mentioned it is not implemented, so we would have to emulate the same behaviour from the proxies. A few questions on that:
- Is there an alternative header that can be set on caddy to have the same effect? Granted I’m new to http language so I don’t know what the intended behaviour is appart for the name and what
handle_response
should be set to. - I believe the
internal
is set in order to deny access from simpleGET
requests on that URL directly. What is the recommended setting to achieve the same?
When navigating to /media/...
I see that the response header has x-accel-redirect
set to a path in _protected
. The intended effect is that when navigating there, the identity is checked if they are allowed to get the file or not, and then the file is retrieved from _protected
.