User is sent to 403 page after successful payment (anonymous checkout)

Created on 28 April 2019, over 5 years ago
Updated 16 May 2023, over 1 year ago

First of all a big thanks for all the great work in this project, thank you very much! It is one of the best documented and supported Drupal modules I know.

But I have an issue, you can reproduce it like this:
1. Create a paid promotion campaign in Instagram or Twitter
2. Someone clicks in an app on his mobile phone on that link and the page opens in the in-app browser of Twitter or Instagram
3. The user does an order (Hooray!) with an anonymous checkout
4. The banking app of the users takes over the payment
5. The payment is successful! (Hooray!)
6. The banking app redirects the user to the payment provider In the regular browser
7. The payment provider redirects the user back to our checkout page /checkout/26896/payment/return?payment_id=9848
8. Because we are in another browser; Drupal does not recognize the user and gives a 403 (Bummer...)

Off course we can fix this with a control-hash in the return URL, but I was thinking maybe Drupal Commerce has already something available to solve this issue?

πŸ› Bug report
Status

Needs work

Version

2.0

Component

Payment

Created by

πŸ‡³πŸ‡±Netherlands sheijtel

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡«πŸ‡·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.

  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 9.5.x + Environment: PHP 8.0 & MySQL 5.7
    last update over 1 year ago
    785 pass
  • πŸ‡ΏπŸ‡¦South Africa janehollander

    Adding cookie_samesite: none to services.yml under session.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.

  • πŸ‡¦πŸ‡ΉAustria agoradesign

    Thanks Ryan! please keep us updated

  • πŸ‡³πŸ‡΄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

Production build 0.71.5 2024