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.

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.

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

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.

#24 fixed it for me.

Subscribe

Found with FF 3.5.6, Drupal 5.21, trying to update from 1.6 to 1.7 of this module, Firefox logged in as uid=1, I instantly get the "Firefox detected a loop" error accessing URL's in the /admin area. Dropping back to 1.6 for now as at least that version works.

I made sure that @ /admin/settings/securepages there were no blank lines in either of the text field boxes. Content ends and no CR/LF is on the last lines of the fields.

I'm pretty sure this is related to #206864: Securepages does not work with Clean URLs enabled. Please try my patch at http://drupal.org/node/206864#comment-2649468

@mrfelton, so which version may that patch be applied to? That post you refer to, the version suddenly jumped as well...

Version: 5.x-1.7 » 6.x-1.x-dev

Like #26 states, we are on D5 and 1.6 of this mod. Thanks.

The patch applies to the version 6 module, but a quick look at the D5 version I can see that the same error is probably present. The problem is in securepages_get_query(), which does not cater for url aliases properly.

All right, thanks for checking. If I get some time I will try to come up with a patch that will work on top of 5.x-1.7. Your diff seems quite small.

mrfelton, what version did you build your diff upon? The official 6.x-1.8? I am having trouble seeing how your diff applies to that build.

My version of securepages is the d6 version, with several patches applied (attached here for reference) - these mostly came from the issue queue somewhere or another. Also, see http://drupal.org/node/206864#comment-2649574 for an updated version of the new patch.

I see gordon is reviewing your proposed patch for D6, so I think I will pause while hashing occurs in the D6 version... let the dust settle just a little. No sense trying to incorporate changes that are yet undergoing review as 5.x-1.6 at least works.

Glad to see progress. Bravo! :-)

subscribing

i was wondering if the patches have been committed for D6 version?
thank you very much!

Yes, #24 is on the right track here. DO NOT hit your enter or return key after the last line of pages to include or ignore. Just make sure the cursor is blinking at the end of the last entry before saving your settings.

Hi all,

Just replace the blank line at the end of textarea (Listed Pages) and this problem will get resolved.

Thanks
Divesh Kumar

I was wondering if anyone had any further information on this?
I'm starting to use Secure Pages on my site more and worried about these critical priority issues.

Ran into this problem this morning, I encountered two issues:

1. I had secured my content creation pages ("node/add/*"), but visiting a path alias of such a page ("network/register", alias of "node/add/network") caused an infinite loop. Adding the alias to the list of secured pages fixed this problem.
2. Visiting the above alias in a different language ("en/network/register") still caused an infinite loop, adding the path alias with the language prefix to the list of secured pages fixes the issue.

Both these problems only happen for anonymous users.

At least in the D7 version of the module, this is caused by path.inc not being loaded for cached pages, so it never gets the path and goes into an infinite loop. Patch attached which loads path.inc if it wasn't already loaded and sets a global ( or else warnings show up )

Please see http://drupal.org/node/587000#comment-4519010.

I had an issue with infinite redirects when I enabled this module. Turns out I already had uc_ssl module trying to handle redirects back to non-ssl pages for anything other than ubercart pages. Disabling uc_ssl and adding cart* to the config fixed this problem for me.

Kim

One possibility if you are having trouble with infinite loops in drupal 7 for the 7.dev version of this module:

1. search for url($url['path'], $url) in the final else clause of the securepages_goto($secure) function in securepages.module
2. print that expression and exit the page before the module has a chance to reload anything
3. see what you get on the screen when you http to one the pages that you have designated to be secure.

In my case I discovered that http://mydomain.com/admin/content remained http://mydomain.com/admin/content
It never became httpS://mydomain.com/admin/content even though the module was trying to rewrite it that way.
Because the module used a method for that purpose that failed to do anything, the page reloaded infinitely on http.

I will describe why in case the explanation is useful to anyone: the drupal url() function has a bug, at least in my case. Documentation says url() will accept an array of keys that determine how to build up the url. One of the keys is 'https' which you can set to true to get an https url. That's what the author of securepages.module is doing when constructing the new url for any page you want to secure. Since the url() function does not respond to the 'https' key like it is supposed to, the new secure url never becomes secure, but remains http, not https. It therefore reloads infinitely.

If you know a better version of this module that resolves this bug, feel free to ping me.
Or if you know something I clearly don't about drupal's url() function and improvements to it.

Graham.

Partly same as #42, but my project problem are as below:
Our site is Multilingual site. it have two languages. One is English(default) another is french. they have different domain.
English has its domain www.xxx.com
French has its domain www.xxx.fr

Everything work fine for both two language https pags can switch back to http page, except for one huge issue. The French home page can't redirect back to http. It cause infinite loop.

1. search for url($url['path'], $url) in the final else clause of the securepages_goto($secure) function in securepages.module in line 203
2. print that expression and exit the page before the module has a chance to reload anything
3. see what you get on the screen when you http to one the pages that you have designated to be secure.

The English home page if you type https://www.xxx.com it will output http://www.xxx.com. But the French home page, if you type
https://www.xxx.com, it will output https://www.xxx.fr. So it always redirect by itself. It will cause infinite loop. It cause browser crashed.

So I update the script like this

//drupal_add_http_header('Location', url($url['path'], $url));
	$redirect_url = $url['base_url'];
	if ($url['path']) {
		$redirect_url .="/".$url['path'];
		if ($url['query']) {
			$redirect_url .='?' . drupal_http_build_query($url['query']);
		}
	}
	drupal_add_http_header('Location', $redirect_url);

And it work fine for my project.

#43 have something wrong when you operate the form search the content at back end at https://www.xxx.fr. You will get the wrong path of the form as below

After I login https://www.xxx.fr/admin/content2, then choose “Article” in the “Content Type dropdown, and click “Apply”, It has been redirected to http://www.xxx.fr/ttps://www.xxx.fr/admin/content2?title=&type=page&stat... and i have checked the module on line 84

  $url = substr(rawurldecode($form['#action']), strlen(base_path()));

So i update it as below

       if(strlen(base_path())!=1){
    	$url = substr(rawurldecode($form['#action']), strlen(base_path()));
	}else{
		$url = $form['#action'];
	}

Simple solution that worked for me... I had put in mydomain.com as both the non-secure base URL and the secure base URL. But it turns out I should have put http://mydomain.com and https://mydomain.com instead. This wasn't documented, but I noticed some of the attempted redirects put mydomain.com/ into the URL repeatedly, which led me to believe it wasn't being parsed as a complete URL. Probably could be addressed as a bug, but easier still would be a simple field description giving http://mydomain.com and https://mydomain.com as examples.

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