Secure page logs user out

Can you check that
$conf['https'] = TRUE;
is set in your settings.php?

A mixed-mode session can only be created on an HTTPS page - if you are logging in via HTTP this could be the cause, since you won't get the secure cookie.

If that doesn't resolve it, try capturing the session with Live Headers and posting it here as an attachment.

Glad you got it working!

I am having this problem as well, even though I DO have users logging in under SSL. The weird thing is that if you're logged in as an admin, it works fine, but if you're logged in as an authenticated user, then you can't make it past the cart page (SSL begins again at checkout).

-yes, I have checked permissions and all authenticated users have access to Checkout
-I have tried EVERY configuration of allowed pages to get this to run, but it only works if the WHOLE SITE is under SSL
-this was true WITHOUT having administrator ROLE under SSL and also true before I put the admin admin/* pages under SSL
-this is still suggestive of this being permissions-related in some way, but WHICH PERMISSIONS? I've tried everything remotely cart- or session-related that I can think of... ideas?
-anonymous users are NOT allowed to checkout. When they click the checkout button, they are redirected to log in - at which point their cart is promptly EMPTIED and they are requested to log in again - in and endless loop between cart -> checkout -> login.

I am running Drupal 7 with Drupal Commerce, on Pantheon.

Any help appreciated.

Thanks,
Kelly

Strangely I just spend a couple of hours fiddling the beta1 release of secure pages and it always logged me out when I went secure. I also saw messages from Chrome saying "This webpage has a redirect loop." I am setting up moneyscripts a little e-commerce package that is written in Drupal.

The same behaviour didn't occur when I disabled the module and just typed the http:// url. I eventually gave up and went with the securelogin module. I have used the Drupal 6 version successfully but not the Drupal 7 version.

A mixed-mode session can only be created on an HTTPS page - if you are logging in via HTTP this could be the cause, since you won't get the secure cookie.

So does that mean that this is an issue with Drupal core, or is it just an inherent limitation of secure cookies? If the former then we should put a reference to the issue on the project page (like the other D7 release blockers). If the latter then we should do something like:
1) on hook_init set a flag to indicate (empty($user->uid) && empty($_SESSION))
2) on hook_exit make the same test.
3) If test #1 was negative, test #2 was positive, and the page is not sent over HTTPS, then watchdog() an error.

@kbell in your situation I'm guessing that somewhere in your checkout workflow a session is created for the anonymous user (probably when they click 'add to cart'). That is the HTTP request that must use HTTPS. Also this bug is probably not limited to Secure Pages module, if you did the same thing with manually switching between HTTP/HTTPS you'll have the same issue.

Dalin, thanks for your comment. Unfortunately I don't know if this is a Drupal core or secure cookies issue. I do know that securelogin forces all users to login securely and then any interaction with the site from that point on stays secure. When I tried to get the same behaviour from secure pages, I got the redirect loop messages which stopped me from getting futher interaction from the site.

The issue I would think is users logging in under https://domain.com/user and clicking around, then coming back and typing in http://domain.com and it appears that they are not logged in anymore.

If you have a Drupal site that secures the user* path and admin* path, when they 'switchback if there are no matches' it looks like they are logged out, except the logged in session is for https.

I've also found that it interferes with the role based redirecting. Once they land back on http://, there is no way back without typing https:// in the URL to get back to the authenticated session.

What necessitates this config:

$conf['https'] = TRUE;

? SecurePages works as it should for me without adding that.

Also, about cart sessions for DrupalCommerce, he is correct.

It almost seems like if you're securing a Drupal application that has authenticated users, you might as well at this point just make the entire site SSL to prevent them from errantly being stuck on the http side without a way back until they fix the core issue mentioned above.

A mixed-mode session can only be created on an HTTPS page - if you are logging in via HTTP this could be the cause, since you won't get the secure cookie.

I think this should be on the project main page.

I think this should be on the project main page.

Better yet, comment #10 has a proposal that would send errors to watchdog if this occurs, since the problem is more complex than just "logging in on HTTP". We just need someone to code it.

Not sure if it's related to securepages, but having some similar issues this evening led me to find that when a user logs in, the session cookie is not refreshed as authenticated with the login page refresh. This results in any boost cached page being served as anonymous because the cookie was never set as authenticated. (boost issue: https://drupal.org/node/1995742)

At this point, I have no idea if it's a securepages issue of not refreshing the cookie during login, a core issue, a login toboggan issue, varnish issue or what :-/

I figured I would post here first to see what kind of response I can get :-) Can anyone else replicate that the cookie is not being refreshed during login and stays as anonymous? Or is it supposed to work that way? (Don't really know how cookie sessions work). I ended up having to create a nasty "refresh" workaround to get it to work right.

Weird thing is, the boost cached home page still won't honor the authenticated cookie, even after my refresh workaround...

We encountered this same problem. We use Secure Pages to run Ubercart and CiviCRM financial transaction pages under https and the rest of the site is regular http. After our upgrade to Drupal 7, whenever Secure Pages redirected to an https page, the user was logged out.

This is actually an issue in core Drupal (version 7.22). You can reproduce the problem without Secure Pages. If you set $conf['https'] = TRUE in settings.php (in order to support both http and https), you can login under http, change the URL in your browser to https, and you'll find you're logged out again, even if Secure Pages is disabled.

The reason seems to be that when Drupal reads in the session variable from the db, if the address was https, it looks for a session with an ssid in the sessions table. Not finding one, it assumes you're an anonymous user.

The attached patch to /includes/session.inc fixes this behavior by altering function _drupal_session_read(). Under this patch, if Drupal doesn't find an existing secure session, it looks for an insecure session with the same uid and session id and uses that session info for the ensuing secure session. We've found that with this patch in place, we can switch back and forth between http and https pages and the user stays logged in.

In mixed-mode sessions, secure and insecure sessions end up stored separately in the db, so there's the possibility of some inconsistency, depending on which pages you've set Secure Pages to force https on. We've found this happening with our Ubercart store, like this:

• (User is in http mode.)
• User clicks "add to cart" on a product. Store posts a message "you've added X to your cart" to the session, then redirects to the cart, which is under https.
• (User is now in https mode. Old session is is used to create the new session, thanks to patch.)
• User completes checkout in https mode with no problems.
• When checkout is complete, user clicks "continue shopping" which takes user back to the http catalog.
• (User is now back in http mode, Drupal uses the pre-https session, and so...)
• User sees (again) "you've added X to your cart," which was the message hanging around in the old session.

This can be disconcerting, but it definitely beats having your users logged out when they go to check out.

Presumably one could make parallel changes to function _drupal_session_write() so that it doesn't create two session records. But I'm not sure of the security implications of making data from a secure session visible back to an insecure session, so I left that alone for now.

@rjlang is there a core issue on this already? Figured I would ask first for a link I can follow instead of trying to hunt down the right issue :-)

BTW, thx for the patch. I'll definitely take a look at it.

@philsward, it looks like https://drupal.org/node/961508 is addressing this issue (https://drupal.org/node/961508#comment-7390636 describes our use case, too).

@rjlang sweet! thanks :-)

#16 Patch worked great! Thanks

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