2278c7f82d
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: > > 1. User visits forum.siteA.com, click login > 2. Gets redirected to idp.siteB.com > 3. Fills login details > 4. Gets redirected to forum.siteA.com/session/sso_login?parameters > 5. Gets redirected to forum.siteA.com/homepage > > On step 4, the response includes a `set-cookie` header, with proper `HttpOnly; SameSite=Lax; Secure `and 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.com` was initiated because of a redirect from a different domain, is it expected that Chrome will silently drop same site cookies from forum.siteA.com? |
||
|---|---|---|
| .. | ||
| assets | ||
| controllers | ||
| helpers | ||
| jobs | ||
| mailers | ||
| models | ||
| serializers | ||
| services | ||
| views | ||