This is a workaround a behavior change in Chromium v97. The following text was sent to the blink-dev mailing list:
This change broke a SingleSignOn login on the FOSS software Discourse. We have a flow like:
- User visits forum.siteA.com, click login
- Gets redirected to idp.siteB.com
- Fills login details
- Gets redirected to forum.siteA.com/session/sso_login?parameters
- Gets redirected to forum.siteA.com/homepage
On step 4, the response includes a
set-cookieheader, with proper
HttpOnly; SameSite=Lax; Secureand set. But if there is an active service worker, the login will fail as that cookie will be rejected by Chromium due to SameSite rules now.
t=2971 [st=258] COOKIE_INCLUSION_STATUS → domain = “forum.siteA.com” → name = “_t” → operation = “store” → path = “/” → status = “EXCLUDE_SAMESITE_LAX, DO_NOT_WARN”
The service worker is a vanilla WorkboxJS service worker that intercepts all GETs with the “Network First” strategy.
Disabling the service worker or using Firefox results in a successful login. There is no warning in either DevTools network tab nor the console that the cookie was rejected.
Chrome 96: login works Chrome 97: login does not work Chrome 98: login does not work
Is this expected behavior? Even if the request
GET forum.siteA.comwas initiated because of a redirect from a different domain, is it expected that Chrome will silently drop same site cookies from forum.siteA.com?