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.

CommentFileSizeAuthor
securepages-HTTP_SSL_CIPHER.patch607 byteskwinters

Comments

kwinters’s picture

kwinters commented
Status: Active » Needs review

status

Anonymous’s picture

Anonymous (not verified) commented
Assigned: Unassigned »

@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

kwinters’s picture

kwinters commented

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).

kwinters’s picture

kwinters commented

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.

grendzy’s picture

grendzy commented
Status: Needs review » Closed (works as designed)

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

kwinters’s picture

kwinters commented

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.

grendzy’s picture

grendzy commented

agreed - we do need to improve the documentation all around for securepages.