0

Before the actual redirection to 3rd party url we are basically storing the user's session id, userid etc in Session so while we return back to our return url for posting data of payment gateway then we will need to update the status by retrieving the user's session, here at this point our session gets cleared/null. This is happening in Chrome for version above 84. Because I am able to maintain users session after redirection also in Firefox browser. I also want to do the same irrespective of chrome versions. How do I maintain session of each user after redirection?

Notes:

  1. I have tried dictionary by declaring it globally and filling values in it before redirect. But that also get error that key not found after post bck to return url.
  2. I have tried session by storing user's info against the txnid that I send to 3rd party url and it sends us back to return url and that gets null.
  3. Cannot store session for each user in database as it will created prob and have load to db.

Any other options to try. Please help. I am using ASP.NET MVC.

Ankita
  • 189
  • 1
  • 4
  • 12
  • 1
    Have you set your session cookie to "SameSite=None" and "Secure" (HTTPS only)? This is a requirement for 3rd party cookies to not be blocked in Chrome going forward – Xerillio Sep 18 '20 at 19:39
  • No not such things I have set. But it works perfect in firefox. Why not in chrome? While researching I found out after chrome updates for version 84 and later sessions are getting null/cleared. And @Xerillio it does move to 3rd party url fine but while posting back to return url it null's the session we stored while requesting. – Ankita Sep 19 '20 at 05:07
  • @Xerillio It is not a third-party cookie. It’s a first-party cookie - but if the user followed a link,
    , or HTTP redirection from a different-site then browsers don’t send certain first-party cookies to prevent potentially harmful cross-origin requests. Browsers won’t send any “Strict” first-party cookies in any cross-origin requests, but they’ll send “Lax” cookies only on GET/HEAD requests, and “None” for all requests but only over HTTPS.
     – Dai Sep 19 '20 at 07:31
  • @Dai if I understand the purpose of Ankitas session(cookie) then it's supposed to be passed on to the payment gateway and back again. That would be a 3rd party cookie. Ankita, I'd suggest you try configuring your cookie with those attributes I mentioned - at least that would explain why you only see this in Chrome – Xerillio Sep 19 '20 at 09:59
  • @Xerillio No, the term "third-party cookie" applies when a web-page embeds content from another origin/site (e.g. an image like those beacon GIFs), scripts or an iframe, so the browser uses the cookies for that other origin/site when making requests for that embedded third-party content. Whereas in Ankita's case, they have a first-party cookie (the ASP.NET-generated Session Cookie: `ASPNET_SessionId`) which is not being sent on a cross-origin request during a redirection. The problem is a missing or incorrectly configured `SameSite` cookie policy. – Dai Sep 19 '20 at 10:20
  • @Xerillio In my case, while I make a request to 3rd party url I am setting session values in one of the params that is being passed with that url. The problem is when it comes back to my websites return url that time session expires. Those param i which I had set my users session is gone/null. – Ankita Sep 19 '20 at 10:40

1 Answers1

0

You need to set a SameSite cookie policy.

Chrome enforces the new SameSite cookie rules more stringently than Firefox, but Firefox will soon behave the same as Chrome.

The exact SameSite option you should use depends on the type of redirection:

  • If the redirection is a HTTP 3xx redirection using GET or POST and all requests are over HTTPS then you can use SameSite=None.
  • If the "redirection" is initiated by a client-side <meta> element or JavaScript using window.location = 'newUrl' then you can use SameSite=None.
  • If the redirection is a HTTP 3xx redirection using GET and not all requests are over HTTPS then you can use SameSite=Lax.
  • If the redirection is a HTTP 3xx redirection using POST and not all requests are over HTTPS then there is no quick-fix: you will need to use HTTPS for all requests.

The SameSite option was added to ASP.NET WebForms and ASP.NET MVC in .NET Framework 4.7.2, though you should be using .NET Framework 4.8. If you cannot update your project to .NET Framework 4.7.2 or later then you can use a trick with IIS' <rewrite> rules to modify response Set-Cookie requests.

You can configure defaults for SameSite in your web.config file, but you'll need to update a couple of different locations:

  • Specify <system.web><httpCookies sameSite="Strict|Lax|None|Unspecified" /> for when you use HttpCookie directly.
  • Specify <system.web><sessionState cookieSameSite="Strict|Lax|None" /> for ASP.NET's own Session cookie (this is the OP's problem).
    • Note that you cannot specify Unspecified for <sessionState> - but you should never use Unspecified so that shouldn't be an issue (Unspecified is only needed if you need to support iOS 12 because Apple Safari did not recognize SameSite=None at the time, but no-one should be using iOS 12 today).
Dai
  • 141,631
  • 28
  • 261
  • 374
  • my proj is already in prod and runs on .net framework 4.5. The solution of doing SameSite=Lax or None can be done if its version is 4.8. I don't think so its a good idea to upgrade the proj on .net framework 4.8 because its in prod – Ankita Sep 21 '20 at 13:06
  • @ankita That’s why you should test it first. – Dai Sep 21 '20 at 22:25