Securepages does not work with Clean URLs enabled

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

Yes upon installing the 5.x-1.6 version I ran the update script. After completing that I checked the secure pages settings link and enabled it (clicking on save settings).

It shows up as enabled, however whenever you browse to a page that should match the filters and become "https" this does not happen. I tried switching settings on the page so that the https was always enabled but again nothing. I also ried disabling and then enabling again but still nothing.

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

Sure my current filter set is:

node/add*
node/*/edit
user/*
admin*
user
node/*/delete

However when I switch to the 5.x-1.6 revision I can try default filters or any combination and much to my frustration no pages ever enter the https state.

The pages that should enter ssl is anything that matches above, such as the admin configuration pages, user login page or other.

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!

I have tried with and without page cache and I have never enabled css compression.

So I figure the cache thing may be a good thing, I instaled the devel module but I cannot find how to empty cache. Can you point me to it?

ok I found it now :)

ok I have performed an empty cache and disabled all caching options but sadly it still does not switch into a secure session (tried from different browser also)

Anyone have any other ideas that I could use?

Is there anything else I can do to get more information on the cause?

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

I do not think so (not sure how to check). I patched in the code posted in that bug and the problem persisted so I doubt that is the problem. (although I was hopeful) :)

It really just seems like it is never able to match the current page with the list of pages to switch into secure mode. grrr

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

Mike,

I should state that I have clean urls enabled also so while I do not know what the problem is, there could be something to your statement.

When I disable clean urls secure pages does not begin working. Do you have a work around in your scenario?

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

For reference I have always had clean urls enabled and secure pages always worked (up until 5.X-1.3) then with any new versions secure pages does not work.

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.

As an additional note I tested this new version on a seperate domain and this time I disabled the old module before upgrading. However again the module does not work.

When I browse to /user to login it does not switch to https, however if I browse directly to https:///user the page remains secure

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.

Tried this out on my system and it worked perfectly! Good find!

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.

That value holds:

/index.php

I got the data by adding:

print $_SERVER['PHP_SELF'];

right before the if statement.

It works properly for me if you switch the comparison to double quotes instead of single quotes. See enclosed patch:

sorry I spoke too soon, adding double quotes fixed it for one of my sites but not a second one. Will have to play with this some more when I get home. :(

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.