Thanks to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23068 we are able to use X-Forwarded-For to pass the client IP via a reverse proxy. Now it would be useful to use other X-Forwarded-* headers like X-Forwarded-Proto in the same way.
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.