Problem when quick order (without account)

[horia]

Hello friends

Problem, here is:   Fresh Thirtybees 1.5.1 installed at arts-online.ro. Locals for romanian package, settings, language, currency etc. Set for one page checkout, try to make an order without  account (quick order). After completing the form when try to save,  a message like "Aceasta adresa nu este a ta" this is in english "This address is not yours" like in picture attached. The client is saved in backoffice clients table. If I try to continue and accept conditions an error shows up, saying something like error  address.

It's annoying, because the client wants one page checkout with quick order. Please help

Thank-you

Horia

[the.rampage.rado]

Unfortunately I'm unable to duplicate this issue in any of my setups. 😞 Tried playing with many settings but failed to replicate it. Any specific settings in this demo store?

[horia]

Thank you for your answer. Nope, no specific settings. Just romanian locals, preferences (single page checkout, quick order activated),  SSL activated, php 8.0, the rest are defaults. If you try on domain arts-online.ro  pick a product, try checkout with quick order, write some data ( romanian zip code is six digits like 442266) try to save and there is.

After some digging it looks like the problem arises al line 226 at OrderOpcController.php, but no php error was logged, as I was capable to find

If you like I can sent you the credentials to have a look at backoffice,  anyway this domain is just for test

Thank you for help and advice

Horia 

 

[datakick]

Do you have any full page cache enabled? Looks to me like your server is displaying HTML content that was generated for different user. 

[horia]

From Performance Settings,  Server side caching -> NO,   so no Use Full Page Cache can be enabled .  What do you mean by your server is displaying HTML content that was generated for different user

Thank you

[datakick]

This error message is a stop-gag measure to prevent leaking information between accounts. 

Information can leak when you have some sort of cache (can be anything - caching module, build in thirty bees FPC, litespeed server cache,... ) that is incorrectly configured. When customer B request the same page, the cache can return html content originally rendered for customer A -- this html can contain personal information about customer A, including his address.

There are other possible reasons for this message to appear. For example, if you have some shipping module that is using the same addresses to calculate shipping costs.  

 

[horia]

Thank you for sharing that info, I did not know that.

But with all caches I was able to find deleted, no litespeed cache enable, fresh install, no modules installed,  and this problem appearing only for one page checkout and works fine for 5 steps standard , it seems to me that this is not a cache problem.

Anyway,  I went to Preferences->Customers and change setting  for Registration process type from Only account creation(default setting)  to Standard (account creation and address creation) and it looks like it solved the problem.

Interesting,  for 1.4 TB version this problem never happens,  I have stores in 1.4 that works fine with that default setting.

Maybe this will be useful for you.

Thanks

 

[the.rampage.rado]

4 hours ago, horia said:

Thank you for sharing that info, I did not know that.

But with all caches I was able to find deleted, no litespeed cache enable, fresh install, no modules installed,  and this problem appearing only for one page checkout and works fine for 5 steps standard , it seems to me that this is not a cache problem.

Anyway,  I went to Preferences->Customers and change setting  for Registration process type from Only account creation(default setting)  to Standard (account creation and address creation) and it looks like it solved the problem.

Interesting,  for 1.4 TB version this problem never happens,  I have stores in 1.4 that works fine with that default setting.

Maybe this will be useful for you.

Thanks

 

With this information I managed to reproduce it on my test site just now.

Tracked here: https://github.com/thirtybees/thirtybees/issues/1745

 

EDIT: It is generally good idea to have Standard setting there as it's more user-friendly.

[the.rampage.rado]

@horia, the issue is fixed in edge channel by datakick. You can update to edge or manually revert the changes in controllers/front/AuthController.php

 

https://github.com/thirtybees/thirtybees/commit/f7abd964a67446a04bb0416d2619db84cd75c80d

[veganline]

I had the same problem. Might be fixed now - thanks! 
Are there any ways to check that caching is off for my ording page, which is called https://veganline.com/order ?
I am on default settings and Cloudflare.

-------edit-maybe I can answer my own question ---------
Cloudflare > Dashboard > Example.com > Rules > Page Rules > Example.com/order > Cache Level: Bypass
Free users get three rules
-----------------------
Example.com/backoffice > Advanced Parameters > Performance > Cache > default settings don't have any full page caches so should be OK
------------------------
DNSchecker.org > your host's site > Lightspeed
If it uses lightspeed and has the cache set-up in a tricky way, I don't know what to do.

Edited January 5 by veganline