secure pages causing infinite loop

I have confirmed this bug - but I'm not sure it's (at least always) related to cache. I disabled caching and am still experiencing this problem. I only need secure pages for one node which passes credit card info, so either disabling the checkbox or cache are not really options. This is definitely critical - it makes the module pretty much useless.

I've got the same issue when enabling the switch mentioned above. I have another problem, in that their appears no way to disable the module in a local environment. Setting the "securepages_switch" to off for my local site still forces an attempted to redirect to HTTPS, which I don't have set up in a development environment.

Same problem here. Can someone please advise those of us who are having this problem. The site I'm working on is supposed to go live in a week...

Same problem here. Can someone please advise those of us who are having this problem. The site I'm working on is supposed to go live in a week...

i realize this issue report is ancient by now, but i'm still seeing this issue with 5.x-1.6 . i have Secure Pages set up to only make a few pages secure: the defaults, plus two other particular paths.

i can verify that either disabling site caching, or unchecking the SP "Switch back to http pages when there are no matches" option solves the problem. (neither of which is really a viable long-term fix, unfortunately.)

i can add a couple of other pieces to the puzzle:

* the infinite loop is only happening for me as an anonymous user (no problems when authenticated)

* i believe the infinite loop is only happening for nodes (e.g. anonymous users can see /user/register with no problem)

anyone else still struggling with this bug and want to help me work on it? module developers, is there any more info we can provide that will help you track this down?

People struggling with this issue should also check http://drupal.org/node/291666 which describes another cause for the infinite loop that is unrelated to caching.

I am seeing this behavior with v 1.6 and Drupal 5.10, and it only happens for anonymous, which is actually because cache is only enabled for anonymous users. Disabling cache removes the problem, so it's definitely caused by cache being enabled. In this case, at least, it has nothing to do with the $_server variable. Anyone have any clues about the interplay with caching and secure pages?

oops ... didn't mean to change the title.

gordon, or anyone else, can you give some tips on the preferred way to test/debug this problem in a development environment? should we just install the certificate locally and modify our hosts file so that the domain the certificate applies to points to our local web server? i'd like to do some testing work here, but am unsure of the related web server / SSL setup steps (and how they interact with Secure Pages) and want to be sure i'm headed in the right direction. (i'm running a pretty standard LAMP stack on Ubuntu.)

You can also just use openssl to create a local, unsigned certificate. Once you create an exception in your browser, it should work the same way.

im experiencing this as well.

was just talking to gordon on irc.

a solution for me was to be more specific as to what i provided in the what is secure pages textarea and what are ignored.

I was having this problem with the user/*/[arg] pages.

I had secured user/*/edit but any page like user/*/addresses (from uc_addresses module) would do the redirect loop.

Adding user/*/* as ignored, fixed this.

I still see this as a bug and not en elegant solution but easy to quickly do without patching the module.

I have given it a test on the dev version and I am unable to replicate this. Please try the dev version and see if you get the same issue.

I get the same problem under Drupal 6.7, but only for certain pages, more specifically for OG related pages. This includes not only og/*, but also any admin/* which links to OG (for example, editing a view of an OG).

I'm not sure if this is the same issue of this thread, but I don't have any clue on what can be causing this.

I can confirm that being specific is important - I had to add <front> to my ignore-list, which surprised me.

sorry it's taken me so long to get back to this -- still seeing the problem, and still hoping to figure it out!

here are some testing steps i've taken on my local development site. presumably 5.x testing is preferred on the 1.7 release now (which would have been dev when gordon last mentioned it above). i've just added one additional path to Secure Pages' "make secure" defaults.

1. Drupal 5.16
   Secure Pages 5.x-1.6

   (relevant) Secure Pages settings...
   Switch back to http pages when there are no matches: checked
   Make secure only the listed pages:
   node/add*
   node/*/edit
   user/*
   admin*
   node/11

   (relevant) Performance settings...
   Page cache -> Caching mode: Normal

2. browse to node 11: Redirect loop
3. Update Secure Pages to 5.x-1.7
4. browse to node 11: Redirected to front page with http (not https)
   browse to user/register: Served https page as expected
5. tried adding 'node/11/*' to my list of 'Ignore pages' per #11 above, but still saw the same problem
6. as originally reported... set caching mode to 'disabled', OR uncheck 'Switch back to http pages when there are no matches' and then browse to node 11: Served https page as expected

any pointers on what testing to try next, or additional info that would be helpful?

[EDIT: and just to reiterate from my #5 above, the problems only occur for anonymous users.]

Watching This -- same issues with 5.x and 5.x-1.7 of secure pages. With caching or switch back to http on I get infinite redirects to the front page particularly and other pages as well.

I can confirm I just experienced this issue in 5.x-1.7 as an unauthenticated user but not as an authenticated user. Adding to the ignore list per #14 did solve the problem. If you need additional information regarding the install please let me know.

bmagistro, can you provide some more specifics about your securepages settings? i assume you have both the "Switch back to http pages when there are no matches" and "Make secure only the listed pages" options selected (and "Normal" caching on your site). what is in your list of "Pages" and "Ignore pages"?

I remember that we had the same issue. But meanwhile we use patched versions of securepages for drupal 5 and 6. Maybe #420712: Front page toggles between HTTP and HTTPS was related to this.

thanks, mkalkbrenner, for nudging me to look at my list of secured and ignored pages again!

in my case, in all my testing i'd simply failed to add the node's alias back to the "Make secure only the listed pages" list. ugh. once i added the alias in addition to the system path i was served the page via https as expected.

(my guess, though i'm not easily able to test it at the moment, is that the extra blank line at the end of my "Make secure only the listed pages" list was confusing my testing earlier on.)

[EDIT: and to clarify, i do appear to need *both* the system path and the alias in my list of "Make secure only the listed pages"]

Is there a fix for this? I am having this problem but it seems my issue might be slightly different. I just enabled the module and was never able to go to the secure pages settings page. idk if it is because i have ubercart installed and the credit cart functionality uses this.

I am also getting this problem, when caching is enabled and secure pages is active always re-redirects to https. When cacheing is enabled and is not in the ignore list it loops between http and https indefinitely.

Once is in the ignore list, then it is redirected to https which is not ideal but will have to do until there is a fix. Not sure whether the problem is cacheing or secure pages. I am also using global redirect and .htaccess forwarding for www. but have tested both of these and am confident that they are not causing the problem.

I'm not sure if this is reliable fix or luck or coincidence but I had a thought when I ran into a problem with another module. In the secure pages configuration there is a simple text box to set the pages which should be secure (a client had issues with the blocks module and blocks not appearing which is what made me think about it).

I checked that there were no blank lines at the end of the textarea, and there were. Secure pages may interpret a blank line as the page??? So I removed the blank lines, and so far there have been no issues.

I'll check over the next few hours to see if has made a difference permanently. It would certainly explain the variety of the issue and that it is not specifically related to anything.

It's worth a try, it seems to have worked for me!

@ #23 purplemine:

See pending patch at #420712: Front page toggles between HTTP and HTTPS to remove empty lines at the end of the textarea.