search

fuel / core

Fuel PHP Framework - The core of the Fuel v1 framework
http://fuelphp.com
813 stars 345 forks source link

SSL reverse proxying #631

Closed krtek4 closed 12 years ago

krtek4 commented 12 years ago

When trying to do SSL reverse proxying for a FuelPHP application, the method Input::protocol() returns 'HTTP'. Since this method is used, for example, to compute the form action url, it can lead to various problems where it isn't the right server which is contacted.

The architecture :

Internet user --> Reverse Proxy (HTTPS, NGinx in my case) --> Web Server (HTTP, Apache in my case)

The problem is FuelPHP is running on the Apache server which is called with the HTTP protocol, but the user access the website through HTTPS, thus the url used for the form action should also be HTTPS.

The common way to resolve this issue is to set the header "X-Forwarded-Proto" to HTTPS when the proxy send the query to the webserver. The application then check this value to return the right URL based on the proxy protocol. This is better explained on the following drupal bug : http://drupal.org/node/313145

I made a pull request yesterday about this issue, but WanWizard raised a valid security concert about my patch : https://github.com/fuel/core/pull/629

I suggest two other ways to circumvent this issue :

1° Add a config value to core to specify the protocol to use when creating URL. I know you can set the base_url value, but I'm talking about something which will enable to set only the protocol.

2° Since my problems is with the automatic URL for form actions, add a config value to form to generate HTTPS url when set.

The second option would also be useful for people having an HTTP website, but decides to send only form data through HTTPS.

WanWizard commented 12 years ago

1° For a global change it's still the easiest just to set $_SERVER['HTTPS'] = "on", either in your index.php or in your config.php.

2°I see a use case for being able to generate secure URL's, independent of the current scheme used. As this will require API changes, it will not be for v1.1.

krtek4 commented 12 years ago

I totally agree that it is really easy to use the solution you provided on the pull request, but as the problem is pretty common, I think that a method to manage this on the framework level has its place.

No problem if it doesn't make it for v1.1, I understand the feature freeze.

WanWizard commented 12 years ago

Implemented the second part of your feature request using an extra parameter to html::anchor() and Uri::create().

As stated before, the reverse proxy situation can be handled in your application, no need to update the core code for that.