-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Support for x-forwarded-proto #943
Comments
This is technically a duplicate of #369 -- I think the conversation there is very relevant. This default On whether I think where it poses a security risk is that it's essentially potentially untrusted input that a reverse proxy either needs to send with an appropriate value or scrub in order for an application to be able to trust the resulting value (which is more complicated when there isn't a reverse proxy, and the application is thus exposed directly to said "untrusted" input). I imagine there have probably been discussions in either the PHP community or the Apache community (or both) predating this one where they've determined that the current state of affairs is the "best" they can do, but it's a bit of a hard thing to search for giving how generic the |
Agree (why didn't that issue show up when I was searching for it? 🙁). Closing this and moving there.
Variables inside (Yes: while formally PHP isn't tied to CGI, there's still lots of legacy behaviour so the above isn't 100% true.) But still, PHP has nothing to do with this decision IMHO. This is either responsibility of the webserver (who could populate variables according to the proxy) or the application (who could handle the headers itself). PHP should limit itself to passing the variables from the webserver.
I think that ~95% of the time, PHP is deployed in a traditional hosting where there's no reverse proxy.
Of course, trusting |
Background
A lot of PHP apps (incorrectly) use
HTTPS
to determine the protocol that the browser made the request with. They then use it to construct the browser URL and determine when to redirect, etc.Thus, when a reverse proxy is placed before the app, the URL isn't constructed correctly and you often get the dreaded "Too many redirects" error. Using reverse proxies is even more common in containers, so images like
wordpress
often patch the code so that the standardX-Forwarded-Proto
header is obeyed and it behaves correctly behind a proxy:Solution
Ideally, every application should be modified to obey reverse proxies, but there appears to be a tendency in the PHP world to, umm, not do that (otherwise I don't understand why these patches are still needed for maintained apps like Wordpress and such).
Manually patching the PHP to set
HTTPS
(as shown above) is error prone, fragile and app-dependent. A better way is adding the following:to the Apache config. It achieves the same, but is much simpler, robust and application-independent. So, we could put it in
/etc/apache2/conf-available/reverse-proxy.conf
and then,a2enconf reverse-proxy.conf
in the Dockerfile is all that's needed to make it work.We could even enable it by default. It would be awesome, especially for new users, but some things should be taken into account first:
X-Forwarded-Proto
beforeHTTPS
, so nothing should be broken.The text was updated successfully, but these errors were encountered: