Cookies and sessions get overwritten when session not detected (after redirect, or ad hoc)

[AmurgCodru]

I'm currently facing a very disturbing error which I was able to replicate on multiple instances and which all lead to a bug in the session manager.

Whenever the cookie is set to SameSiteStrictMode then a new session gets created instead of reusing the old one.

Example: A user is doing an online purchase and from the checkout, gets redireced to stripe,paypal, whatever, then upon payment or cancellation (s)he gets redirected back to a success or cancellation page. But instead of showing that page, the user's greeted with the login page (due to the token not working)

This also occurs out of the blue on many occasions when the user simply refreshes the page without a logical explanation. Debugging the LoadAndSave function did indeed show that a new cookie/token was regenerated.

	sessionManager := scs.New()
	sessionManager.Cookie.SameSite = http.SameSiteStrictMode
	sessionManager.Cookie.Name = "my_session"
	sessionManager.Cookie.Secure = true

The bug is replicated with both badgerstore and sqlitestore

I've experimented for hours on different days to figure out the best settings.

Setting SameSite to LAX seems to temporarily mend this issue.

The problem would be forgiven since samesite strict disallows sending cookies, then a simple refresh would normally work and the user would still be logged in. However, if the token/session is rewritten then it's a new session so it creates friction and purely refreshing does not work anymore.

And yes, I'm redirecting to the same domain.

[jum]

This is basically part of same site strict mode means, your cookies will not cross site boundaries when using third parties like payment services or oauth flows. The easy fix is using lax mode. I fixed the issue by remembering my cookie state behind the code token that is send back in oauth flows and merging the session values into the new session. May be the payment flows have a similar feature?

[AmurgCodru]

This is basically part of same site strict mode means, your cookies will not cross site boundaries when using third parties like payment services or oauth flows. The easy fix is using lax mode. I fixed the issue by remembering my cookie state behind the code token that is send back in oauth flows and merging the session values into the new session. May be the payment flows have a similar feature?

1. That the cookie is not sent in Strict Mode is true, when I'd refresh, then I'd expect the existing cookie/session to be passed AND to be logged in again, currently, a new session is issued which breaks the existing application. I'd imagine many scenarios where this breaks, including when someone clicks on a link they've received via email or simply sharing an link to view a specific page.
2. Such a token/session could be useful, however they kind of introduce the extra security hassle and bugs associated with such implementations, yet they don't not fix point 1.

All I can think about are hacky solutions (such as an extra lax cookie as to NOT reissue a session). Or a way to set the cookie to lax before sending the user to a payment processor and then back to strict after the payment is finalized/cancelled.

Indeed, lax mode is what I've used and seems to be the true solution for the problems outlined in point 1. and above with new sessions being issued.

[alexedwards]

@AmurgCodru I'm not sure what the problem here is. What you're describing sounds to me exactly like the correct and expected behavior for SameSite=Strict and SameSite=Lax, and not a problem with this repository at all. If you want the session cookie to be sent when a users is navigating from a different site (which it sounds like you do), then SameSite=Lax is the appropriate setting and totally fine to use.