Securepages does not work with Clean URLs enabled

Did you run the upgrade script or enable secure pages on the settings page?

Can you please post the filters that you are using and which page that should be going to SSL and is not.

i had the same issue.
on http://sfk.org

(drupal 5.6)

secure-pages 5.x-1.5 works fine (' https://sfk.org/en/donate ' - is the secure page on our website)

but when i upgraded to 5.x-1.6 - i got only blank page (in IE, IE7, firefox, safari)
and the address didn't change to 'https'
same issue when i upgraded to 5.x-1.x today.

so... i just went back to 5.x-1.5
let me know if there's any additional info i can provide that will help you solve it.

Can you clear your cache.

The only thing I can think of is that it is not getting to the hook to change pages.

Also how are you caching. Are you using agreesive?

(btw - for some reason the problem occurred also in ver 5.x-1.5...

i installed devel module, and did 'empty-cache'
didn't help.

i went to performance settings, and change it from 'normal cache' to disabled, and disabled css compression.

everything worked fine!

i upgraded again the module to 5.x-1.6
and it still work fine.

turned on normal cache + css compression,
and it works!

seems like the combination of turning off caching, and clearing cache - did the magic :)
thanks!

This path that you list, is this an alias to something like node/123 as this could be related to http://drupal.org/node/211850

Has anyone come up with a fix for this yet? Or an idea as to where the issue is?

Ok, I seem to have tracked it down somewhat - it has something to do with clean urls being enabled.

-Mike

I should probably mention that my clean urls are enabled by having rewrite rules in apache for them - I assume the issue would be the same with an .htaccess file, but I guess I will need to test that.

-Mike

Not yet - it is definitely related to Clean URLs, though. Apparently, you cannot use Clean URLs while having SSL enabled. I wonder why it there doesn't seem to be too much attention to this issue: it seems like a rather important problem.

-Mike

I could only get it to work by using the node ID rather than the url alias.

I.E.

pay-online - doesn't work
node/188 - works

Not really a huge issue for me as I only have 1 payment form.

Edit - admin/ works too.

I located the problem on the line 20 in securepages.module. Development version is also affected. Following condition is always true:

basename($_SERVER['PHP_SELF']) != 'index.php'

I think it useless. I attach a patch that works for me.

The main reason that this it to stop secure pages from working on other pages like update.php which secure pages from break.

Please let me know what $_SERVER['PHP_SELF'] is on your system.

Updating title to help make this issue easier to find.

See also "URL aliases are ignored"
http://drupal.org/node/211850

My problems with this issue disappeared when I enabled

RewriteBase /

in Drupal's .htaccess file. The relevant line is the third one below (line 101 in the default .htaccess file)

# If your site is running in a VirtualDocumentRoot at http://example.com/,
# uncomment the following line:
# RewriteBase /

(Securepages 6.x-18 / Drupal 6.13)

RewriteBase / didn't do it for me. Unless I turn off chaching alltogether I actually get errors stating connection problems! Very strange!

With some links I even get a 404 error unless I turn off switching back to http.

It may help to clear the browser cache ;-) and Drupal's cache of course.

The "Pages which will be be secure" should list "user*" instead of "users/*" to include the login dialoge.

Is this module working with cleanurls enabled on Drupal 6.x?

Yes, clean urls works perfectly under D5 and D6. The patch attached does absolutely nothing.

A phanomenon I observed is that secured pages at times are not delivered and Drupal instead brings up the start page. This is wired, since it appears that at times it works as expected and at other times it doesn't. For a while I thought it had to do with cached pages, first those on the server side and second on the browser side but that didn't prove to be true. Now I am at wits' end and turned it off again. Anybody who can second my observation? Better, anybody who knows the cause?

Spade: I can confirm your observations of weird, intermittent behavior. In my case it acted up for a number of days on a production D5.18 server then with no changes has worked flawlessly for two months now. Sorry, but I have no explanation.

#34/35: That seems unrelated / off topic, really; could it have any resemblance to this CleanURLs issue?
Anyway, out of curiosity: is that also experienced for D6, or only on the 5x version?

Well, since I didn't see what the cause is, I thought I share my observation here, because I am using CleanURLs as well.

In the meantime I suspect an issue in regard to URL aliasing. I first only placed the nodes in the "Pages which will be be secure" section. After also adding the path alias, things seem to work more reliably. Maybe a hint to this effect in the documentation would help.

Kind regards,

Frank

If only the node of a page is entered and the alias of this node is called, often (not allways) the start page is called instead. Only if the alias is entered as well, does is seem to work reliably.

This needs alt least to be documented in a reame.txt file and on the project page.

(Sorry, I ment to open a new issue, but it didn't work this way.)

Yes, that should be a separate issue. Changing the title back.

Please try with this patch. It has solved the issue to for me.

Powered by Dreditor.

+++ securepages.module	(working copy)
@@ -23,10 +23,14 @@
-  if (!variable_get('securepages_enable', 0) || basename($_SERVER['PHP_SELF']) != 'index.php') {
+  if (!variable_get('securepages_enable', 0)) {
     return;
   }
 
+  if (basename($_SERVER['PHP_SELF']) != 'index.php' && basename($_SERVER['PHP_SELF']) != '/index.php') {
+    return;
+  }
+  

Why are you splitting this up over 2 lines?

Also the basename() will never = '/index.php'

+++ securepages.module	(working copy)
@@ -407,7 +411,11 @@
+   $path = $query['q'];
+   if (function_exists('drupal_get_path_alias')) {
+     $path = drupal_get_path_alias($query['q']);
+   }
+  return trim(str_replace('q='.$path, '', $_SERVER['QUERY_STRING']),'&');

I am not sure why you are doing this as the url is converted into the alias when the secure url is built

Powered by Dreditor.

I split it over two lines because with the additional condition one line became too long and a little unreadable. However, you are absolutely right that basename($_SERVER['PHP_SELF']) will never equal '/index'. This part of the patch can safely be removed (I didn't actually mean to include it in the first place, it was left over from my testing/debugging.

In responce to your second question... The original code used

return trim(str_replace('q='.$query['q'], '', $_SERVER['QUERY_STRING']),'&');

That does not work when the path is accessed as an alias with clean urls enabled, because in that case $query['q'] actually equals node/1234 but $_SERVER['QUERY_STRING'] equals the aliased version, so the q= get parameter is not stripped from the URL, so when the second url is built, q= is passed in in the query parameter to securepages_url(). This results in an incorrect URL which causes securepages to not redirect properly.

Take this example, with an alias of:

/some/alias -> node/1234

Being accessed as

http://example.com/some/alias?extraparam=1

before the patch, this would result in the following url being passed to Location (which screws with securepages and can result in an infinite loop):

https://example.com/some/alias?q=some/alias&extraparam=1

after the patch, this becomes:

https://example.com/some/alias?extraparam=12

Updated patch that removes the unneeded change in hook_boot.

ok, whist the above patch does work well in most situations it doesn't quite cut it in multilingual sites where a path prefix is used. I think the approach is wrong and have come up with this simple alternative to rework the function in question:

/**
 * Return a querystring without the q parameter
 */
function securepages_get_query($query) {
  unset($query['q']);
  return http_build_query($query);
}

As far as I can tell, all the function needs to do is to strip out q= in the querystring. The above does exactly that - no need for pattern matching or alias look ups.

Damn, the above has some issues with double encoding. This one seems better:

/**
 * Return a querystring without the q parameter
 */
function securepages_get_query() {
  $query = array();
  parse_str($_SERVER['QUERY_STRING'] , $query);
  return trim(str_replace('q='.$query['q'], '', $_SERVER['QUERY_STRING']),'&');
}

I have a multilingual site and looking for help on this issue.
I will be using Ubercart + Secure Pages module for credit card payment
I use prefixes for my website to change the language
www.example.com
www.example.com/fr
www.example.com/en

which patch should I apply to fix this issue? will the patch be committed in the near future?
thank you very much!

This module doesnt seem to work at all for me (I have clean urls enabled) on a 6.x clean installed drupal with just this module and ubercart installed. I assume it simply does not work at all with clean urls and that defeats the whole purpose of the site. It seemed to work ok with no clean urls enabled, so I abandoned all hope as the author seems to think that there is nothing wrong. So I deleted it and used this instead until this module has all it's bugs worked out. It's pretty rudimentary but it worked for me to get ubercart secured. It basically does the exact same thing this module does, only it does it in about 10 lines heh. I simply made me a new module, called it uc_ssl, and enabled it, and put the following code in it. Works like a charm. BTW, this only works if your ssl domain name is the same as your regular non-ssl domain name. If they are different, then just replace the $_SERVER[HTTP_HOST] with whatever your secure and non-secure domain names are. Kinda simple really. It works with both POST and GET type URLs.

//
function uc_ssl_init()
{
   //If the site is in secure mode on a non-cart url then switch to non-ssl to save a little on encrypting resource usage.
   if ($_SERVER['HTTPS'] && arg(0) != 'cart')
   {
      drupal_goto('http://'.$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']);
   }

   //If on a cart url, use HTTPS and re-post/re-direct to the SSL version of the url.
   if (!$_SERVER['HTTPS'] && arg(0) == 'cart')
   {
      drupal_goto('https://'.$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']);
   }
}

@crystaldawn #47 -- I've got Secure Pages working fine on 6.16, but it's not the Dev version. It's 6.x-1.8, with the latest Ubercart.

Were you able to set up a keys directory outside of your root directory, and have you got open_basedir set to point to it?

If you're on a Media Temple DV, you may need to check both the "Enable SSL" and "Enable SSL to work in the same directory" options in the Plesk panel under domain setup. (not sure of the verbiage for the second checkbox)

...great little piece of code for a workaround, tho. :)

*Note: Stupidly, I jumped in w/o realizing that most of the issues pertain to multi-lingual stuff, which mine is ~not~...sorry. :/

I cannot get securepages to work with clean URLs and AllowOverride None. I have moved the directives from .htaccess into httpd.conf per http://drupal.org/node/43788. My clean URL rules in httpd.conf are now as follows:

  # Rewrite URLs of the form 'x' to the form 'index.php?q=x'.
  RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
  RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d
  RewriteRule ^(.*)$ /index.php?q=$1 [L,QSA]

Secure Pages simply doesn't redirect. When I turn off clean URLs, it works. When I set AllowOverride All and use the standard .htaccess file, it works with clean URLs.
I have tried this with Drupal 6.16, 6.17, SecurePages 6.x-1.8 and 6.x-1.x-dev (2010-May-11).

How can I make Secure Pages work with the clean URL settings in httpd.conf? Thanks!

You cant do this with SP. It was not designed to work with clean urls at all and is completely unsupported. This problem has existed for well over 2 years but has never been resolved. Other SSL solutions do exist although they do not involve using SP at all. You can see one of them in my profile ;)

#50 Yes this issue has been around for a long time, because I have not been able to replicate this myself, and anyone who has experienced the problem has never been able to give adequate information, or allow me access to there system so I can debug the issue on their system so I can track down the issue.

I have never had this issue, and never been able to replicate it. And any information I received didn't give me any information that would help me solve the issue.

If someone who has the problem can give me access to the system so I can investigate I will be happy to fix it. Just contact me via my contact page and we can work together to fix this issue once and for all.

If would be nice if this could be fixed for Drupal 7.

Gordon.

I didnt have SP's long enough to actually figure out the problem myself, but my own module ran into similar issues and it was because of the way I had it checking to see if SSL was trying to be accessed in the first place. Check out this example and the documentation from PHP behind it, maybe this is the issue and would fix it for these people, I dont know but it works perfectly for mine when people reported a similar problem. I also noted this in one of the issue queue's here in hopes maybe it would get to you but I guess it has not. Read this issue and see if maybe it would pertain to SP's or not:

http://drupal.org/node/797326

Note the comment I put in it

"I bet this is why secure pages fails on some servers completely if it's looking for the word 'on' like you had in your example. Perhaps if that is indeed what they check on, then someone should tell them that it should be changed to something similar to what I've just put up instead."

This module is considerably smaller in scope and vastly different in design and intended use than SP's and thus was probably easier to debug to find this hard to find bug. But if it helps, then it was worth finding.

I think most drupal sites have Clean URLs enabled right?
I'm not seeing an issue with this at the moment. I will definitely post detailed explanation if I do come across an issue.
Thanks

Never seems to work properly for me without this the change I described some months ago. Here is an updated patch that applies cleanly against the 6.x-1.9

I think this is a different issue, we had

cart/*
cart/

in our required pages, and it seemed to screw up clean URLs. When we changed it to

cart*

it worked as expected.

@djdevin you should probably use this instead:

cart
cart/*

I've also been unable to replicate the issue.