Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
When making account creation compulsory is rather pointless.
Steps to reproduce:
- admin > user management > user settings
- disable email verification
- admin > ecommerce settings > store
- set anon purchasing policy to flexible or registered only
- admin > site building > modules
- enable cart block somewhere on the site
- Start another browser
- Add 1 or more items to the cart
- Go to checkout
- Register a new account
- Look at cart in side bar and swear a few of times
- Scratch head
- Go buy from another site
I am unsure if the bug is in drupal core, ec cart or ec payment - I will leave you to sort that out
This has the potential lose business, which isn't good. I have only put this at normal, even though I think it is pretty critical, but I don't know the convention.
Sorry if this a dupe, I tried searching first :(
Comment | File | Size | Author |
---|---|---|---|
#19 | user_login_2.patch | 764 bytes | gordon |
#11 | user_authenticate_tasks.patch | 4.61 KB | JohnAlbin |
#10 | user_login-HEAD_0.patch | 792 bytes | gordon |
#5 | user_login-HEAD.patch | 760 bytes | gordon |
#2 | user_80_0.patch | 540 bytes | gordon |
Comments
Comment #1
skwashd CreditAttribution: skwashd commentedI noticed this bug in ecommerce, it turns out that the problem was in user.module, reassigning. One of the ec devs (gordonh) helped with the patch.
Comment #2
gordon CreditAttribution: gordon commentedWhen the user setting "Require e-mail verification when a visitor creates an account" is not enabled the user is logged in without calling hook_user('login'). This is a problem for E-Commerce when it is trying to move the cart from the anonymous user to the newly created user, and thus the cart is lost.
Comment #3
gordon CreditAttribution: gordon commentedComment #4
drummDoes not apply.
Comment #5
gordon CreditAttribution: gordon commentedActually this was for 5.1, but here is a version for 6-dev
Comment #6
gordon CreditAttribution: gordon commentedBump, I need to get this into HEAD so that it can be backported to Drupal 5.x
This is giving me headaches for Drupal 5.x E-Commerce users
Comment #7
sammys CreditAttribution: sammys commentedThis is a problem with Drupal 5. A very serious problem at that. Why has this not been dealt with?
Comment #8
gordon CreditAttribution: gordon commentedAfter speaking with Killes I was informed that I needed to get this into 6.x-dev first and then he would include it in 5.x-dev.
I know this is a big problem in 5.1, but I need to get this into 6.x first, and then it can fix our problem.
Comment #9
Dries CreditAttribution: Dries commentedThis looks OK, but can you sprinkle that code with some code comments? Thanks.
Comment #10
gordon CreditAttribution: gordon commentedHere is an update to the patch for HEAD.
Comment #11
JohnAlbinI think this points at a more general problem: hook_user('login') isn’t called consistently and neither are the other tasks associated with a successful login.
All of the appropriate tasks occur in
user_login_submit()
which is called when a user completes the user login form:But not all of those tasks are completed in the other places that users are logged in:
user_pass_reset()
(one time password),user_register_submit()
(register and login immediately),blogapi_validate_user()
,drupal_login()
.Those login tasks should be called the same place where the actual login occurs; namely where the user is loaded into
global $user
inuser_authenticate()
I’ve attached a patch that consolidates those tasks into one place.
Not generating a new session ID when logging in is a security issue. Isn’t it? :-s
Comment #12
drummI'd rather go with a much simpler change than the patch in #11 for 5.x.
Comment #13
gordon CreditAttribution: gordon commentedYes my patch just fixes the missing call, which is much better, esp for 5.2
Comment #14
JohnAlbinI’ve moved the patch in #11 to “User login/authentication tasks not performed consistently” so we can get Gordon’s issue into 5.x quicker. :-)
I’ve looked closely at Gordon’s patch in #10 and it is RTBC.
Comment #15
Gábor HojtsySo it looks that this patch is against 5.x and the 6.x stuff which needed more fixes is moved into another patch.
Comment #16
drumm#10's patch does not apply in 5.x.
Comment #17
gordon CreditAttribution: gordon commented#2 is for 5.x and #10 is for HEAD
Comment #18
drummNeither does #2.
Comment #19
gordon CreditAttribution: gordon commentedI have rerolled that patch and should be working now.
Comment #20
drummCommitted to 5.x.
Comment #21
gordon CreditAttribution: gordon commentedThis needs to be ported to 6.x, see if #10 commits
Comment #22
JohnAlbinGordon, I’m already working on getting it fixed in 6.x. The patch in http://drupal.org/node/152497 includes your fix as well as the more general problem I described in #11 above.
Comment #23
(not verified) CreditAttribution: commented