Posted by kwinters on September 15, 2009 at 4:17pm
Jump to:
| Project: | Secure Pages |
| Version: | 6.x-1.8 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | paulbooker |
| Status: | closed (works as designed) |
Issue Summary
In function securepages_is_secure, it is only checking one of the possible $_SERVER vars.
Patch attached will also check for HTTP_SSL_CIPHER, which will also only be found on HTTPS. Note that I made it using SVN, so the version headers won't quite match up.
| Attachment | Size |
|---|---|
| securepages-HTTP_SSL_CIPHER.patch | 607 bytes |
Comments
#1
status
#2
@gordon
This is something i would need to investigate in order to understand the problem. Would you
share any insights you have and i'll come back to this a little later.
Best,
Paul Booker
Appcoast
#3
In my particular case, SSL was being handled by an F5 load balancer instead of Apache. Because of this, the HTTPS status ended up in a different $_SERVER var.
My patch shouldn't harm any existing functionality, since it behaves exactly the same in a typical install (where Apache handles HTTPS).
#4
Any updates on this?
I've been running the patch for months now, so my special case is working. If you can confirm that the normal case still works after the patch is applied (SSL directly through Apache without a load balancer, etc.) then this should be safe to commit.
#5
There have been a number of similar issues - my view is that there's an unlimited number of possible proxy configurations and custom headers. It would be impractical for securepages to attempt to accommodate them all.
The good news is that it's easy to configure your load balancer / proxy to account for this. You can use apache mod_env or just use settings.php to manipulate $_SERVER['HTTPS'] directly. I've written an article that addresses the f5 specifically:
http://www.metaltoad.com/blog/running-drupal-secure-pages-behind-proxy
#6
We used secure pages specifically because it was impractical to configure dozens of sites in the balancer.
The settings.php approach could work in that context, but if you're going to encourage that then I'd suggest making it more obvious within the module FAQ.txt, etc.
A setting for the variable name or a hook would also be good approaches.
#7
agreed - we do need to improve the documentation all around for securepages.