Page not found or Access Denied after payment

I confirm this issue.
I test 2 cases, always as user authenticated :

• When permission "access checkout" is set to anonymous : /checkout/%order_id/payment/return/%payment_redirect_key return 404 not found.
• When permission "access checkout" is not set to anonymous : /checkout/%order_id/payment/return/%payment_redirect_key return 403 access denied even if we are authenticated.

In the function commerce_checkout_access (commerce_checkout.module) the authenticated user is saw as anonymous.

I can also confirm I've been impacted by Chrome's recent changes to handling cookies that don't have samesite=None set. I don't have all the answers, but I'll share some notes/thoughts.

Upgrading to PHP 7.3 and setting the ini configuration option (session.cookie_samesite="None") seems to be an option that doesn't require code changes. This is the first version of PHP that added support for configuring the samesite cookie attribute for PHP session cookies. This version (7.3) also is apparently the latest version that Drupal Commerce works well with. Upgrading a website from PHP 7.2 to 7.3 is currently the way forward that I'm most strongly considering.

Proposed resolution
Will need to enforce `SameSite=None` rule

I'm on the fence about this proposed resolution, for a few reasons. Drupal Commerce does not seem to me an appropriate place to change this PHP session cookie attribute, even though Commerce is impacted. Also, without upgrading PHP to 7.3 or higher, my current understanding is that Drupal core's session handler (drupal_session_start()) would need to be changed. I searched the Drupal core issue queue, and it looks like there is currently no proposal for changing this. I developed an experimental core patch (for a website on PHP 7.2), but it seems it may have caused a small number of my custom use cases to fail.

Also, the entire Drupal 7 contrib module ecosystem was kinda built with an implicit assumption that samesite=None is how Drupal behaves. Only for Drupal 9 is there an issue to start using samesite (Lax).

Some thoughts on another possible way forward (I haven't thought it through too far yet):

I'm wondering if maybe it's wise to look for a way to support session cookies that aren't as inherently vulnerable to CSRF attacks (i.e. samesite="Strict" or samesite="Lax"). In theory, I think that Drupal Commerce can be modified to do this. Basically it would involve identifying the user by some other means (than the PHP session cookie) and triggering their session to resume. For example, somehow use the payment redirect's return URL to determine which session to resume - and give back the user the cookies they're supposed to have.

For added security (protection against a compromised payment processor hijacking and resuming a user's session), possibly in addition to using the unique return URL, use another cookie or LocalStorage value given to the browser prior to them following the payment redirect (a cookie that the payment processor has no visibility of, but the browser retains after returning).

The biggest problem I see with pursuing this approach is that it will take time to develop and test, and Chrome users are being impacted in the here and now.

For anyone who's interested, I've created a Drupal core issue for supporting samesite=None on PHP < 7.3, and provided a patch there.

Same issue exists on commerce 2, should I open an other issue ?

I'm having this issue also in D7 and it's been very frustrating for our customers. I went and updated my settings.php file to set session.cookie_samesite="None", however, there are still a number of users still experiencing the issue in certain versions of Chrome it seems.

I may have to try one of the patches in the issue that @nullkernel mentioned in the issue posted for Drupal core.

@nullkernel I tried your patch in comment #8 of the post you referenced "ISSUE#3170525 Set samesite cookie attribute for PHP sessions". However, we still seem to be encountering users who are getting the Page Not Found error. Any other ideas?

I'd like to add that my site is having this same issue. We are using D7 with PHP 7.3 and Drupal Commerce. We direct users to a third-party vendor to process the credit card, then redirect the user back to an order confirmation page.

I tried putting ini_set('session.cookie_path', '/; samesite=None'); in the settings.php file, but that did not work. The user was not redirected to a confirmation page, but rather the home page. And the order was not processed (no record of the order and no confirmation email was sent). Is there something I'm missing?

Thanks.

Ok I think I'm narrowing down why some users are still having this issue on my site despite applying the patch by @nullkernel (and also setting session.cookie_samesite="None" in settings.php).

I noticed that when a user selects a product and adds it to their cart before they login, that when they do proceed to their cart and get prompted to login (and then they login) that somehow the SameSite cookie value gets overwritten from "None" to being empty. Any ideas why that would happen or where to fix that?

I think if I can figure that part out then it will resolve this issue for good.

Today we started experiencing issues with the Add to Cart button. The updated version of Chrome Version 87.0.4280.67 on Mac (and current version of Safari on Mac) now allows multiple clicks on the Add to Cart button, hence allowing a user to add a product to the cart more than once (once for each click of the Add to Cart button). I realize this issue with the cart button is not directly related to the 404 error (which we are still having), but wanted to share this here as it may be related to session cookie. Perhaps it is not related. If so I will open a new ticket. Anyone else having this issue with Chrome (appears to happen with both Mac and PC).

@axle_foley00 did you ever find out why the SameSite cookie value gets overwritten from "None" to empty when an anonymous user proceeds to the cart and is redirected to log in? I'm having this issue with the latest version of Drupal commerce and Google Chrome on both MacOS and Windows 10. No problem when the user logs in first and then proceeds to the cart.

Thanks

@SergFromSD, yes it seems Drupal's sessions are regenerated whenever you login after adding to the cart initially. So Drupal Commerce will start an anonymous session when you click on the Add To Cart button and then when you go to login, Drupal will regenerate that session and then the details of that previous anonymous session gets added to the new (logged in) session. However, the SameSite cookie setting isn't set when it regenerates the session. So you'd need to ensure that when that happens you again set the SameSite cookie setting. The Patch in comment #11 in Issue 3170525: Set samesite cookie attribute for PHP sessions helped with this. I did have to make a slight modification though. See comment #26 on the same issue.

Hope that helps.

I'm sorry for drupal that cant fix this major bug that interrupt whole site functionality.
because chrome is most popular browser today and with this bug we cant sell product and create eCommerce website.
after this long time no valid and official solution...
time to move on!

A fix was committed to Drupal core on March 23rd: #3170525: Set samesite cookie attribute for PHP sessions.

Anyone having issues should try testing the -dev release of Drupal core, and report back issues in the linked core issue.

Drupal 7.79 was released with the fix.

I am not sure how to configure the SameSite cookie attribute with my Drupal 7 Commerce site (using PHP 7.4). I thought I could do it in the settings.php file, but that doesn't seem to work for my needs. Any suggestions?

The issue has been resolved by upgrading the simplesamlphp library to 1.19.0. This upgrade provides a means to set the SameSite cookie attribute to none (and secure). This appears to resolve our issues with a cookie being deleted after processing the payment and returning to the Drupal 7 Commerce site.

I had the same issue , and resolved it by adding ini_set('session.cookie_path', '/; samesite=None'); in settings.php.
I am using:



chrome version: 116.0.5845.187 
PHP 8.2.8  

Drupal: 9.5.9
centarro/commerce_kickstart: "^3.0"

I am not sure why the fix mentioned in the comment #15 is not there D9.