Summary: | Support X-Forwarded-* headers | ||
---|---|---|---|
Product: | Koha | Reporter: | David Cook <dcook> |
Component: | Architecture, internals, and plumbing | Assignee: | Bugs List <koha-bugs> |
Status: | CLOSED WORKSFORME | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | m.de.rooy |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23068 | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: |
Description
David Cook
2020-05-04 00:10:12 UTC
Comment hidden (obsolete)
Actually, looking at https://github.com/plack/Plack/wiki/How-to-detect-reverse-proxy-and-SSL-frontend and https://metacpan.org/pod/Plack::Middleware::ReverseProxy, it looks like Plack-enabled Koha can already reset headers based on X-Forwarded-* headers... but we just don't set them in out-of-the-box Apache... (In reply to David Cook from comment #1) > Actually, looking at > https://github.com/plack/Plack/wiki/How-to-detect-reverse-proxy-and-SSL- > frontend and https://metacpan.org/pod/Plack::Middleware::ReverseProxy, it > looks like Plack-enabled Koha can already reset headers based on > X-Forwarded-* headers... but we just don't set them in out-of-the-box > Apache... Plus that won't help for CGI Koha, although maybe we really do need to focus on killing off CGI Koha... Thanks to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21267, the X-Forwarded-Proto header gets set in Apache when using Plack, so Plack::Middleware::ReverseProxy will set the $ENV->{HTTPS} to true. (With CGI, you'd need to add the headers in your reverse proxy, but Koha doesn't have a mechanism for using X-Forwarded-Proto for CGI Koha.) Thanks to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23068, there is support for X-Forwarded-For for both Plack and CGI Koha. (mod_proxy_http in Apache should automatically add headers for X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Server). I guess Plack::Middleware::ReverseProxy runs too and takes care of the first reverse proxy which will be Apache on the local machine... Plack: - Apache should set X-Forwarded-* headers so that they can be consumed by Plack::Middleware::ReverseProxy CGI: - Apache should set HTTP headers using X-Forwarded-* headers from a separate reverse proxy? -- It makes sense that the community maintain the Apache configuration in the Plack context I suppose, but perhaps it doesn't make sense for CGI, since 1) we don't recommend CGI, and 2) you don't have to use a reverse proxy out of the box. -- But then Bug 23068 has set a precedent by adding Plack/CGI support for the X-Forwarded-For header. Support which is really useful. There are so many different levels where these things can be handled with their own pros and cons... I do not understand what this report is about. We already have support for X-Forwarded headers. So what is the point ? (In reply to Marcel de Rooy from comment #5) > I do not understand what this report is about. We already have support for > X-Forwarded headers. So what is the point ? It's been a while since I reported this one, so I'm not 100% sure of my original intent. I didn't word it very well. However, in Koha, we actually only use X-Forwarded-For and X-Forwarded-Proto. Bug 23068 explicitly uses X-Forwarded-For, while X-Forwarded-Proto is used by Plack::Middleware::ReverseProxy to set $ENV->{HTTPS} to true. Apache's mod_proxy_http automatically sets X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Server, I believe, but doesn't do others like X-Forwarded-Proto (which is why Tomas added it in Bug 21267). AWS load balancers pass X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Port. I mostly see utility for X-Forwarded-For and X-Forwarded-Proto. Not really sure why a person would care about X-Forwarded-Port I think I'll close this one for now. |