- π«π·France nicolasgraph Strasbourg
I faced to the same issue using the commerce_payzen module because of the return mode set to POST. It does work using GET.
- last update
over 1 year ago 785 pass - πΏπ¦South Africa janehollander
Adding
cookie_samesite: none
toservices.yml
undersession.storage.options:
worked for me.parameters: session.storage.options: ... cookie_samesite: none
- πΊπΈUnited States rszrama
I finally experienced this issue myself today thanks to Drupal 10 setting the SameSite cookie attribute to Lax as of [#3275352]. Setting the value to None in my site's
services.yml
did the trick. I'm open to the idea that we should change our own access checker, but the issue is that it does leave the possibility open for an anonymous user to spoof a return for an authenticated order, where just adjusting the cookie attribute solves it more fundamentally.I just don't know what other implications changing this to None might have ... it was obviously set to Lax for the sake of hardening the Drupal application against cross-site request forgery attacks, but I can't imagine we'd document how to set it back to None if setting it back actually left a site insecure.
In the meantime, I'll figure out how to document this so folks can find it. I'll at least be including instructions in the CyberSource module, which is where I've been working.
- π³π΄Norway zaporylie
Seems like we're discussing the same problem but with 2 different origins here:
- redirect from the offsite gateway via POST - this is where SameSite cookie will help
- redirect from offsite gateway to default browser with no user-session as the checkout was initiated in the non-default browser, most commonly - in-app browser (facebook, Instagram, etc) - in that case, SameSite cookie won't help. - π¦πΉAustria agoradesign
Exactly... I believe, finding a solution for the different browser scenario would automatically fix the first issue, regardless of SameSite cookie settings