The module is having no effect at all. It's not breaking anything and configuring it is easy and hitch free. It just isn't doing squat. Concering the variable $_SESSION['securepages_redirect']. It is set to "1" when I land on a page that's supposed to be encrypted and it's not set when on a page that is not to be encrypted. That makes sense, but the logic in the module is the other way around. It's designed to fire the redirect when the opposite condition is met.

This doesn't make sense to me.

if (!isset($_SESSION['securepages_redirect'])) {
securepages_redirect();
}
else {
unset($_SESSION['securepages_redirect']);
}

CommentFileSizeAuthor
#4 Picture 4.png118.84 KBcdesautels

Comments

grendzy’s picture

grendzy commented
Category: bug » support
Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

Is your web server by chance behind an HTTP proxy? In order for securepages to work the value of $_SERVER['HTTPS'] has to be accurate.

cdesautels’s picture

cdesautels commented

What do you mean by "accurate". If the page is loading in htttp:// then then it doesn't exist. If the page is loaded in https:// then it's set to "on".

grendzy’s picture

grendzy commented

ok, that's fine. Some sites use proxies that terminate SSL so $_SERVER['HTTPS'] is always empty.

Can you post your settings from /admin/build/securepages ?

cdesautels’s picture

cdesautels commented
StatusFileSize
new Picture 4.png118.84 KB

Here are the settings. At least what I would like them to be. Curiously, the base url settings will not stick. They'll match what ever protocol I'm using to load the page. If I load this admin page in http, they'll both be http://. Like wise for https://

And of course this is possible because the page is not redirected no matter what protocol I use.

cdesautels’s picture

cdesautels commented

Oh yeah, to answer your earlier question, yes, the server is behind a html proxy and a firewall.

michaelscappa’s picture

michaelscappa commented

My two cents as I was able to enjoy this odd behavior with Chris... I'm no longer sure it is a secure pages issue but may be a core problem, although Secure Pages was the only place I was ever able to see anything like this

within the securepages module, calling variable_get('securepages_base') and variable_get('securepages_base_ssl') both return the value of the non SSL version IF called within the site under http. If I use the https version of the site, they both return https://...

Oddly, this behavior ONLY happens within the module, as calling variable_get in the theme layer returns the correct results. I can 100% confirm that the serialized values in the variables table are the correct values. To make it even weirder: direct db_query/db_fetch_object on the variables table from within the module layer also produce the incorrect values, but on the theme layer does not. Say our example is www.domain.com....

Under http within a module:

variable_get('securepages_base') set to http://www.domain.com and returns http://www.domain.com
variable_get('securepages_base_ssl') set to https://www.domain.com and returns http://www.domain.com
variable_get('securepages_base_ssl') set to https://wwwt.domain.com returns https://wwwt.domain.com
variable_get('securepages_base_ssl') set to httpss://www.domain.com returns httpss://www.domain.com

Calling these from the theme layer produce the expected results. The global $conf, when called from within a module, contains the incorrect values, even though the DB has the correct ones...

cdesautels’s picture

cdesautels commented

Thanks for the detail Michael.

cdesautels’s picture

cdesautels commented

A viable alternative to Secure Pages?

http://drupal.org/node/53567

Thoughts?

Although in this instance we've already decided to force the site to be all https, all the time, at the server config and uninstall Secure Pages. Although, we're having to implement step one in the page above to lock down the cookies.

grendzy’s picture

grendzy commented

using full-time HTTPS is certainly stronger. In that case you might also consider setting the strict-transport-security header: http://hacks.mozilla.org/2010/08/firefox-4-http-strict-transport-securit...

astonvictor’s picture

astonvictor commented
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