Hi, been debugging my system 4.0.1.1 in depth to track down why the "login as customer" function from admin works for primary store but not my second one.
Ive replicated this problem on vanilla install, so not sure if this is expected behavior or a bug.
if the 2 stores are on the same domain but different subs then it works with strict, bit if the are different primaries than it doesnt.
The interesting thing is that the first call the the front end account/login|token passes and starts the session correctly in the db, but for some reason the cookie is never passed back after the redirect to account/account. if i halt execution before the redirect and load the url to be redirected to in a new tab im logged in and no problems...
Strict will block the session cookie on the first request from being redirected from the other domain. This is probably stopping the login_token being associated with the session.
You will probably need to stick with Lax if you want to login as a customer to store on a different domain.
You will probably need to stick with Lax if you want to login as a customer to store on a different domain.
it seems like it is creating a cookie for the sub shop domain when loading the token front end function, i can see it in the browser cookie storage
re lax from my quick research it seems that its generally not suitable for auth purposes ?
re lax from my quick research it seems that its generally not suitable for auth purposes ?
Subdomains are considered to be same site. So sub1.example.com and sub2.example.com would work with SameSite set to Strict. Totally different domain wouldn't.
I was thinking about it more myself, and i think the problem is from the redirect chain, as i looked at each step in dev bar.
- the initial call to domain1.com/administration/index.php?route=customer/customer|login when you click the link to login sends your current cookie (with the critical OCSESSID id to link you to your db session) to setup the process token
- this then redirects to domain2.com/account/login|token to do the front end login which even though no OCSESSID cookie is sent from client with the request, because you have a token it passes
- this then redirects to domain2.com/account/account after success login, also not sending any new/updated cookies, which then fails the load as no cookie and redirects to login page
So it seems the problem is standard redirect behaviour, that it never sends or sets a new cookie for client each step, you only have the one you start with in the redirect chain, which in the case is for a different domain.
I can think up a few workarounds, ill see which works best, roughest is just to break the redirect chain at say the customer/customer|login point, and provide a link that you click on, this will restart the cookie process on the correct domain.
- the initial call to domain1.com/administration/index.php?route=customer/customer|login when you click the link to login sends your current cookie (with the critical OCSESSID id to link you to your db session) to setup the process token
- this then redirects to domain2.com/account/login|token to do the front end login which even though no OCSESSID cookie is sent from client with the request, because you have a token it passes
- this then redirects to domain2.com/account/account after success login, also not sending any new/updated cookies, which then fails the load as no cookie and redirects to login page
So it seems the problem is standard redirect behaviour, that it never sends or sets a new cookie for client each step, you only have the one you start with in the redirect chain, which in the case is for a different domain.
I can think up a few workarounds, ill see which works best, roughest is just to break the redirect chain at say the customer/customer|login point, and provide a link that you click on, this will restart the cookie process on the correct domain.
On more recent OC versions, '|' has been changed to: '.' in the URL to call the method which could be the reason why you might be facing similar situation with '|' since web servers from various hosts encountered an issue by using this character in the URL as this issue has been fixed already.haydent wrote: ↑Sat Jun 01, 2024 4:47 amI was thinking about it more myself, and i think the problem is from the redirect chain, as i looked at each step in dev bar.
- the initial call to domain1.com/administration/index.php?route=customer/customer|login when you click the link to login sends your current cookie (with the critical OCSESSID id to link you to your db session) to setup the process token
- this then redirects to domain2.com/account/login|token to do the front end login which even though no OCSESSID cookie is sent from client with the request, because you have a token it passes
- this then redirects to domain2.com/account/account after success login, also not sending any new/updated cookies, which then fails the load as no cookie and redirects to login page
So it seems the problem is standard redirect behaviour, that it never sends or sets a new cookie for client each step, you only have the one you start with in the redirect chain, which in the case is for a different domain.
I can think up a few workarounds, ill see which works best, roughest is just to break the redirect chain at say the customer/customer|login point, and provide a link that you click on, this will restart the cookie process on the correct domain.
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
thanks for suggestion but thats not it, the login function with token is working just fine
i made a issue for this as im sure its a bug, but daniel, true to form just closes right away saying there is no bug yet his comments make me think he doesnt understand my report... yet his abruptness never allows time to explain...
https://github.com/opencart/opencart/issues/13981
i made a issue for this as im sure its a bug, but daniel, true to form just closes right away saying there is no bug yet his comments make me think he doesnt understand my report... yet his abruptness never allows time to explain...
https://github.com/opencart/opencart/issues/13981
Great! So if that solves the issue, please add [SOLVED] to the start of the post title.haydent wrote: ↑Tue Jun 04, 2024 8:58 ami made a simple fix here, https://github.com/opencart/opencart/pull/13985
UK OpenCart Hosting | OpenCart Audits | OpenCart Support - please email info@antropy.co.uk
Legendary Member
That's a shame, hopefully Daniel will re-read your report.haydent wrote: ↑Fri Jun 07, 2024 4:45 amno surprise, he closed my pull request with no commenthaydent wrote: ↑Tue Jun 04, 2024 8:58 ami made a simple fix here, https://github.com/opencart/opencart/pull/13985
UK OpenCart Hosting | OpenCart Audits | OpenCart Support - please email info@antropy.co.uk
Legendary Member
I know, as I feel with the only 1 comment he did make to my original issue report he didnt understand the problem, and that he thought i was trying to use/login to the admin on one of the 'addon' domains, which is not the case.
Who is online
Users browsing this forum: No registered users and 2 guests
