I've got an Uberkore site being tested right now, and I pretty much have all pages run in standard http mode except the "Cart/Checkout" page where users would enter then personal details and credit card information.

However, if a user attempts to add a product to their cart in a non-secure page, the cart shows up empty on the cart (secure) page because the session isn't being shared. Obviously, this is a problem regardless of using a shopping cart or not.

This problem didn't seem to happen in the 6.x version, so I'm assuming that the 7.x port is missing something.

Comments

Doomd’s picture

I meant ubercart in the above description (not uberkore).

Doomd’s picture

This solution from the single sign on module issues might be relevant here:
http://drupal.org/node/724438#comment-2642326

grendzy’s picture

Component: Code » Documentation

Thanks for testing 7.x! I believe the cause is you need to enable core's mixed session handling. This is accomplished by adding
$conf['https'] = TRUE;
to your settings.php.

This obviously needs to be documented - It's on my todo list but if someone wants to volunteer to help write some docs, that would be awesome too. Ideally we'd have a good README.txt with this module, and perhaps some more info about the secuerpages module at http://drupal.org/https-information

Doomd’s picture

Status: Active » Fixed

That did the trick. Thank You.

JohnZaibatsu’s picture

Adding
$conf['https'] = TRUE;
to settings.php didn't helped me.
I still lose session when switch between http/https.
What else I missed?

I'm a little hopeless. I studied Drupal6 3 moths to prepare everything for my project and mostly nothing is working in Drupal7 this way.
[localization, https-ed login only, custom content type,...] :(

Status: Fixed » Closed (fixed)

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

metastate’s picture

I am attempting to secure a single node (Webform) that anonymous users will fill out. When I am logged in as a site admin and visit the node (https), my session is no longer valid. When I return to another page (http), my session is working again (I can view admin links, edit content, etc.)

When I add $conf['https'] = TRUE; to settings.php and visit the https page, the session breaks completely and Drupal seems to log me out - when I return to an http page there are no admin links. However, the session is still active in the database (there is both a session for an anonymous user and the admin user).

I am also receiving this PHP error in my log: Undefined property: stdClass::$timestamp in _drupal_session_write() (line 173 of .../includes/session.inc). I think this error is being thrown when I leave the https page and return to an http page.

I also tried adding the https base url to settings.php as per http://drupal.org/node/1066156 but that did not have any effect either.

Looking through some other issues, I am guessing this is still being addressed in the 7.x.1.x-dev version:
http://drupal.org/node/1050746
http://drupal.org/node/961508

Just thought I'd mention my scenario. For now, I've left conf['https'] = TRUE; out of settings.php because I'd rather the session break temporarily only on the https page, than disappear all together.

grendzy’s picture

The first time you enable $conf['https'], the sessions table will be out of sync. Logging out and back in should clear it up. If you are making this change to settings.php on an active site you may want to just "TRUNCATE sessions" in SQL to clear out any old session data.

metastate’s picture

Yes, I have tried emptying the sessions table, logging in and out, and flushing the site cache. But I still lose my session completely when $conf['https'] is enabled and I go to an https page. I have to login to the site again and again, and each time a new session is created in the database.

I'm not concerned about trying to fix this though, since I'm able to work around it. If other people aren't having this same problem it's probably due to some other configuration on my site. Thanks!

OldAccount’s picture

I'm having the same problem-- adding $conf['https'] = TRUE; to settings.php and clearing the sessions table didn't work, the session still doesn't carry over.

OldAccount’s picture

Fixed! Found a core patch that fixes this issue: http://drupal.org/node/1050746#comment-4229334

handsolo’s picture

Status: Closed (fixed) » Needs work

did anyone find a fix for using the $conf['https'] = TRUE; with ubercart SSL?

I had this problem - without the $conf['https'] = TRUE; the anonymous user would not be able to proceed from cart to cart/checkout - it would redirect to cart and never move to checkout (payment info)

After adding $conf['https'] = TRUE; to the settings.php then anonymous users can continue to cart/checkout from cart however if you log in then anytime you click on cart or cart/checkout you get automatically logged out -- this is killing me - I have installed on drupal 6 the same module and everything works fine - only having this problem with drupal 7

anyone have any idea what I may be doing wrong here?

grendzy’s picture

Status: Needs work » Closed (fixed)

handsolo: you'll need to apply the patches listed in the issue summary for #952820: Drupal 7 port.

webservant316’s picture

Issue summary: View changes

I am still experience session problems when visiting HTTPS pages with the securepages module.

I am using Drupal 7.26 with no patches and securepages 7.x-beta2. When "$conf[https] = True;" in settings.php the session is always completely wiped out after visiting an HTTPS page and I have to login again. When it is not set and I also REMOVE the login form ids from the Securepage settings page "List of form ids which will have the https flag set to TRUE", then at least I can visit HTTPS pages. However, when on the page my session is NOT recognized, but when returning to HTTP pages it is again recognized.

I cannot figure out the recipe of settings to get this essential module to work properly. Any help?

webservant316’s picture

Priority: Normal » Major
Status: Closed (fixed) » Active
webservant316’s picture

Wow - surprising that Drupal 7 is not functioning smoothly with an HTTPS module for mixed mode sessions. I've been fighting with this for a day! How can others even be using this on a commerce site? I see that the Drupal site itself appears to always be on HTTPS. Maybe that is the solution, do not use mixed sessions?

I followed the directions at https://drupal.org/project/securepages. Since I have Drupal 7.26 installed I could not use #13, https://drupal.org/comment/4196144#comment-4196144, so I used #100 instead, https://drupal.org/comment/8241501#comment-8241501. I also could not use #71, https://drupal.org/comment/6391460#comment-6391460, so I used #232, https://drupal.org/comment/8361131#comment-8361131. After setting $conf['https'] = TRUE; in settings.php is was not better off, but continued to permanently lose my session on HTTPS pages. Then I tried https://drupal.org/project/securelogin but with further problems.

Current I have a configuration with securepages that only loses the session when on HTTPS pages, but regains it when on HTTP pages. Fortunately, I can limp along with this for now.

Any idea when this will get straightened out?

webservant316’s picture

I cannot even seem to set securepages to be secure all the time. Wouldn't this bypass the concern about the mixed mode session bug in Drupal core? Yet when I tell securepages to make everything secure it does not listen to me.

MrPeanut’s picture

Priority: Major » Normal
Status: Active » Closed (fixed)

@webservant316 - Apply these patches:

Set $conf['https'] = TRUE; in settings.php.

Make sure your web server has SSL configured. If you happen to use nginx, see #1504486-2: Can't force https on authorize.php (gives AJAX error).

If your configuration is correct, that will work, and it will keep sessions. I've been using it successfully for over a year, including on Drupal 7.26.

webservant316’s picture

ok - that worked. thanks. I thought https://drupal.org/comment/8241501#comment-8241501 was better than #13, but apparently not.

Saoirse1916’s picture

Seems like this doesn't work with 7.27.

d.olaresko’s picture

the fix that works for me #2283711 - mixed mode fix
without any additional patches from #18 comment except $conf['https'] = TRUE;