A common method of working on sites is to use different browsers on the same PC to see the site from logged on state admin state and user states. I also wanted to be on as user1 and as an admin-user so I logged on as an admin-user in another browers(in this case apple safari) after already being on and continuing to be on as user1 in firefox. Well suddenly i get this text banner saying that the secure pages modules is denying me access. Well as it turned I couldn't get to any pages designated as ssl-secured in the secure pages module set up, in this case /user* and admin*. So I went over to my firefox thinking I'll just turn off secure pages temporarily only to find I was also access denied in firefox as user1. No matter how many times I tried to relog on as user 1 or as the admin-user I was denied. At first I thought it was secure pages itself but soon determined that it was the securepages_prevent_hijack module after reading the modules via ssh.

Not want I wanted really. So I deleted the securepages_prevent_hijack and was finally able to relog on and uncheck it from the modules list following witch it disappeared from the list.

I'm using securepages plus encryption of the password for now until this is addressed or I figure something else out.

Comments

grendzy’s picture

grendzy commented
Title: securepages_prevent_hijack » banner saying that the secure pages modules is denying me access
Status: Active » Postponed (maintainer needs more info)

I'm having trouble reproducing this. A couple of things:

-- can you confirm you're using the latest 1.4 version?
-- What version of securepages do you have?
-- you mentioned "plus encryption of the password", can you clarify what you meant by that?
-- Can you think of any other installed modules that might also interact with the login process?
-- Can you list the settings you have at /admin/settings/securepages ?
-- Are you using clean URLs?
-- Is drupal in a subdirectory, like example.com/drupal ?

thanks.

abaddon’s picture

abaddon commented

im having a similar if not the same issue, ive managed to get around the access denied error by closing my browser, setting the computer date 1 day back and logging in again, it worked ok, actually it seems im getting the same error again.. not sure how to fix it but disable this module for now

logging in at /admin/
POST request with my user/pass returned a redirect to the same admin page AND a SSL SESSION cookie from this module, with the expiration time set +1 second ahead of request time
the GET for the redirect request above was 1 second after but it didnt contain the SSL cookie, hence the access denied error.. i imagined the issue was related to the expiration time which was set in GMT and my local time, not sure how firefox handles these though

-- can you confirm you're using the latest 1.4 version?
-- What version of securepages do you have?
latest of the 2 modules as of today

-- Can you think of any other installed modules that might also interact with the login process?
also using cookie_check logintoboggan persistent_login

-- Can you list the settings you have at /admin/settings/securepages ?
Enable Secure Pages: Enabled
Switch back to http pages when there are no matches: Yes
Non-secure Base URL: http://subdomain.example.com
Secure Base URL: https://subdomain.example.com
Pages which will be be secure: Make secure only the listed pages.
node/add*
node/*/edit
user/*/edit
admin*
Ignore pages:
*/autocomplete/*
*/ajax/*

-- Are you using clean URLs?
yes

-- Is drupal in a subdirectory, like example.com/drupal ?
no, but subdomain, ssl cookie is like ".subdomain.example.com" whereas the session one is without the first dot "subdomain.example.com"

basically the problem is with the SSL_SESS cookie not being passed on the next request after login, could that be caused by the very short expiration time? what else could cause it?

abaddon’s picture

abaddon commented
Status: Postponed (maintainer needs more info) » Active
grendzy’s picture

grendzy commented
Status: Active » Fixed

with the expiration time set +1 second ahead of request time

Ah, that was the crux. You have session.cookie_lifetime set to zero, right? I've just committed a fix. Please try the next dev snapshot and let me know if it works.

abaddon’s picture

abaddon commented

thank you, i can confirm the fix works (ive actually just backported the fix part into the stable version)
the SSL_SESS cookie gets set till "End of session" in firefox now

session.cookie_lifetime was set to zero like you noted as advised by the persistent_login module
"When using Persistent Login (module), it (session.cookie_lifetime) should be 0 so that PHP sessions end when the user closes his/her browser."

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.