Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Anonymous user after putting some stuff into the cart and logs in before checkout looses all of the cart when authenticated.
The problem is with incorrect usage of session_id() in uc_cart.module. The login process regenerates the session id right before login in order to inhibit session fixation.
Below is a patch which resolves the issue with uc_cart.
(Also this was reported on the ubercart.org site: Anonymous user loses cart contents after login)
| Comment | File | Size | Author |
|---|---|---|---|
| uc_cart_session_id_replace-0.patch | 1.46 KB | mtolmacs |
Comments
Comment #1
rszrama commentedWill review... this needs to happen. fwiw, I haven't had any problems since the fix in UC 1.3 for the change in Drupal. I'm not sure how comprehensive the change should be for now, but if we're ditching the session ID we may as well turn the field into an integer in the DB... although, that might not be best since we want authenticated carts to persist indefinitely (based on uid).
Will have to think about it after the review...
Comment #2
mtolmacs commentedUsing the session is fairly common to store the cart id in many webshop applications. For that matter, if you think about it the HTTP session concept was born to solve exactly such problems. The session holds data regarding the user who owns it. The cart (or its id as an abstraction of the cart) falls into this definition because it belongs to one and only one user.
The patch I sent simply replaces session id with a session variable which is managed exclusively by the developer, which is generally not true for the session id itself. The concept you created is still the same and valid in my opinion.
Comment #3
Island Usurper commentedConsidering that this issue got broken again in Drupal 6 (#313570: Logging in empties cart), we decided to implement this in Ubercart 2.0. Since Drupal keeps track of the variables in $_SESSION without us needing to worry about the actual session id, this is a good solution, and probably what we should have done in the first place.
Comment #4
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.
Comment #5
john_wind commentedI have the latest (beta3) Ubercart installed (Drupal 6.6). No matter what settings I choose such as allow anonomys checkout, non logged in users click on a product and click "add to cart" and rather than going to the order process, the message is just (cart empty) with no other options? Please help. Thanks. --J
Comment #6
rszrama commentedSupport requests should be directed to the support forums. This sounds like a caching or missing UID 0 issue, and those are addressed by others in the forums. Also, the latest version is beta5. : )
Comment #7
GregoryHeller commentedi'm seeing this problem in 6.x.2.x-RC3
Comment #8
rszrama commentedComment #9
rszrama commentedGreg, I wasn't able to duplicate on my latest test site, http://amazon.commerceguys.com. Could you maybe give it a go there and put steps in here to reproduce the issue? It may be related to SSL or something, but I figured I'd try it on a vanilla site first.
Comment #10
GregoryHeller commentedi tried on your site and it works as you indicate. I followed all the same steps and it did not work on my site. I thought it might have something to do with uc_node_checkout other than that, i think the all of the same modules are involved on my site as your test site, though i am also using a class rather than the default product, and I am using attributes.
I created a normal product on my test site, with the default product content type, and no uc_node_checkout and tried, and i got the empty cart after login.
I also tried with no attributes and still same result.
any ideas on how else i could debug on my installation? or anything i should look at?
Comment #11
rszrama commentedCan you confirm your Drupal version? I know that somewhere along the line they changed the way the login form was working and I had to accommodate it.
Comment #12
GregoryHeller commentedDrupal 6.10 (will be upgrading shortly) and ubercart 6--2-rc3
Comment #13
GregoryHeller commentedwe are no longer having this problem. In our case i thin kit was due to a trigger that sent the user to the home page after login, that and perhaps also related to the way we were adding data to the uc node checkout node.
Comment #14
Island Usurper commentedComment #15
viggy_prabhu commentedyes, even I was facing the same problem but after I unassigned the trigger it was solved. Thanks Gregory Heller for mentioning the solution here.
Comment #16
agence web coheractio commentedHi,
I'm having the same issue.
Could you please tell me which trigger is it and where I can unassign it ?
Thanks
Laurent
Comment #17
agence web coheractio commentedComment #18
agence web coheractio commentedFound the bug : login restrict (submodule of domain access) is causing it.
When desactivated, ubercart works perfectly when registering users.
Laurent
Comment #19
robertoguzman commentedi have the same issue with ubercart 6.x-2.2 and drupal 6.17
Comment #20
waltercat commentedI'm having the same issue as well. I have the following options set:
user settings = Require e-mail verification when a visitor creates an account (unchecked)
user settings = Visitors can create accounts and no administrator approval is required. (checked)
Logintoboggan settings = Redirect path on registration: (blank)
Logintoboggan settings = Redirect path on confirmation: (blank)
Is there something else I am missing? When an anon user goes to checkout, he gets prompted for login on the login page. When registering he is sent to the homepage. When logging in he is sent to the user page. How do I make it so he is directed back to the checkout or cart?
Comment #21
zarudnyi commentedI found that user loses contents if I check "Set password" option on Logintoboggan module settings page. Without that option all work fine.
Thanks.
Comment #22
tr commentedComment #23
zarudnyi commentedComment #24
rszrama commentedaluminium, the reason TR closed the issue is because yours is not the same as the original post. I'm going to close this again and would request you to instead post a new issue with an appropriate title and full description of the problem you're experiencing. Thanks! : )
Comment #25
garyg commentedHappened to me too.
Disabled the "Login Destination" module and all is well.