I'm having a very bizarre problem with this module on a highly secure server configuration. The server sits behind a proxy and firewall. Secure pages cannot retrieve the correct base urls to function. Let's just forget about Secure Page's ability to calculate the base urls on the fly and focus on the scenario where the secure and non-secure base urls are manually set.

First of all let's be clear, the strings that are stored in the variable table are correct. But when secure pages pulls them from the DB they come through translated into the currently active protocol. That is, if the page were in is "http", then the secure base url is changed to "http". If the current page url is "https", then the non secure base url is converted to "https". I'm guessing that Secure Pages then merrily goes on it's way with the rest of it's task, but with the base urls having been changed like this the net effect is as if the module were not even installed.

We tinkered around with a number of things, but called it a night when reading the strings from the database directly and printing them to the screen still resulted in their being changed. i.e...

die(variable_get('secure_pages_base_url_ssl'));

This printed the url to the screen but it was changed to http://

What is changing these values so persistantly?

CommentFileSizeAuthor
#2 Picture 4.png118.84 KBcdesautels

Comments

grendzy’s picture

grendzy commented

variable_get() doesn't read directly from the database - it returns elements of the global $conf array.

The string "secure_pages_base_url_ssl" doesn't appear anywhere in version 1.8 - where did you see that value?

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

How does this relate to the issue at #946108: Secure pages not working at all ?

cdesautels’s picture

cdesautels commented
StatusFileSize
new Picture 4.png118.84 KB

Sorry, a typo. The variable I was talking about was "securepages_basepath_ssl" inside the function "securepages_baseurl()". Your info as to where variable_get() pulls it's data could be significant, but the weirdness goes further. We tried reading the string directly from the database with db_query() and printing it to the screen and exiting the system and the value still came through altered.

Settings screen grab is attached. This is what I save it as, though this isn't what really appears when you load the page. If I load the admin page as http://, Both the Base URL values come through as http://...

If I load the admin page as https://, then the values are both displayed as https://...

ahmed.sajid’s picture

ahmed.sajid commented

Hi cdesautels,

Have you been able to find a solution? I am having the same issue.

Cheers,
Ahmed.

cdesautels’s picture

cdesautels commented

The problem in my case was not a bug. It turned out to be that the proxy server was not allowing the client IP number through. This is typical of proxy servers. They send there own IP number as the $_SERVER['REMOTE_ADDR'], which isn't very useful. There is another $_SERVER value available that can contain the correct IP, $_SERVER['HTTP_X_FORWARDED_FOR'], but proxy servers typically set this to nothing.

Here are some typical configs.

1. Not Use Any Proxy Server:
REMOTE_ADDR = IP address of client
HTTP_VIA = No value or No display
HTTP_X_FORWARDED_FOR = No value or No display

2. Use Transparent Proxies:
REMOTE_ADDR = IP address of proxy server
HTTP_VIA = IP address of proxy server
HTTP_X_FORWARDED_FOR = Real IP address of client

3. Use Normal Anonymous Proxies:
REMOTE_ADDR = IP address of proxy server
HTTP_VIA = IP address of proxy server
HTTP_X_FORWARDED_FOR = IP address of proxy server

4. Use Distorting Proxies:
REMOTE_ADDR = IP address of proxy server
HTTP_VIA = IP address of proxy server
HTTP_X_FORWARDED_FOR = Random IP address

5. Use High Anonymity Proxies (Elite proxies):
REMOTE_ADDR = IP address of proxy server
HTTP_VIA = No value or No display
HTTP_X_FORWARDED_FOR = No value or No display

In our case, the one in use was number 5 and the hosting security team was not willing to change it. The only solution they gave was to encrypt the entire site which is what we ended up doing.

cdesautels’s picture

cdesautels commented
grendzy’s picture

grendzy commented
Status: Active » Closed (works as designed)

Closing per #4.