When I enable Secure Pages module it causes infinite loops for any page I assign to it as a secure page. I also have a fix, which I will submit as a patch including this issue number. Basically, securepages.module has a function called securepages_goto($secure) where the module reconstructs the url to be secure. The module uses drupal's url() function and an array of keys for controlling the function. The function seems to ignore the https key so when url() builds the new url as a secure one, the https part does not actually happen. It's a bug with url(), I think, and there is an issue about it on the url() api page. My suggested solution (see patch) is to use url() to build the new secure url, but also check the results of that action to make sure it worked. If it did not work and the url still starts with http:// instead of https://, then do a string replace of those items.

Comments

prograham’s picture

Status: Needs review » Active
StatusFileSize
new1.4 KB

HERE IS A PATCH FOR THIS ISSUE:
The patch basically preserves the original approach to the url rewrite for pages that ought to be secure, but then it checks the resulting url to make sure it did in fact change from http:// to https://. If it did NOT change to https:// this patch then updates the url to use https:// like it ought to.

prograham’s picture

Status: Active » Needs review

Changing status to needs review.

grendzy’s picture

Status: Active » Postponed (maintainer needs more info)

Please make sure to follow the issue summary template, and in particular include detailed steps to reproduce your issue. Step one in your report should be install Drupal core from scratch. Any information you can provide about your server is useful too. Because of the difficulties in reproducing others' server environments, the level of detail needed is perhaps a bit higher than in other issue queues.

edulterado’s picture

The patch didn´t work in my case.

Before applying it, I made a WGET to get further info about the infinite redirect and this is the response which is thrown endlessly:

Connecting to sub.domain.com|000.00.00.00|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://sub.domain.com/ [following]

after applying the changes of the patch, the infinite redirect persists, and this is the looping response for the front page of the site that should not be accessed in SSL BTW:

Connecting to sub.domain.com|000.00.00.00|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://sub.domain.com/ [following]

It´s worth mentioning that I´m using Drupal 7.17 and I´m experimenting the loops while trying to apply some work arounds for this issue #1037542: Session broken between http and https related to mixed session handling between HTTP and HTTPS that makes Ubercart products added to the shopping cart in a non-secure mode to be lost when visiting the cart page in a secure mode. Odd enough, the only solution I found so far for preventing infinite redirects from appearing is removing the $base_url line from settings.php or disabling the Drupal cache for anonymous users (the redirects are not appearing for logged-in users), although none of these solutions addressed the Ubercart issue.

I have a development version of Drupal running in my laptop - the same codebase, modules, .htaccess, etc... than production server - and it´s working perfectly: no infinite redirects, no broken sessions between HTTP and HTTPS. So I´d like to hear more details about what are the possible server environment variables that I should take into account.

UPDATE: This was very useful for understanding and fixing the infinite redirect loops in my case #1406686: HTTPS/HTTP, drupal page caching, and base_url break caching.

astonvictor’s picture

Issue summary: View changes
Status: Postponed (maintainer needs more info) » Closed (outdated)

I'm closing it because the issue was created a long time ago without any further steps.

if you still need it then raise a new one.
thanks