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?
Did not post this in the
https://bugs.chromium.org/p/chromium/issues/detail?id=1241188 because it's
not public.
On Tuesday, November 30, 2021 at 5:27:47 PM UTC-3 [email protected]
wrote:
> On Tue, Nov 30, 2021 at 3:24 PM Joe Medley <[email protected]> wrote:
>
>> >Since the first part of the change is in M97 I updated the chromestatus
>> entry to indicate that as the release and added a note that the
>> redirect-chain change is coming in M98.
>>
>> Is any of this feature usable in 97?
>>
>
> Yes. Requests without a redirect will work in M97 and get the expected
> origin header, sec-fetch-site header, and samesite cookies. Some
> restrictions redirected requests will only start being applied in M98.
>
>
>> Joe Medley | Technical Writer, Chrome DevRel | [email protected] |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Mon, Nov 29, 2021 at 7:11 AM Ben Kelly <[email protected]> wrote:
>>
>>> Thank you!
>>>
>>> FYI, I realized this morning I made one small mistake in my original
>>> post. The origin propagation part of this intent is actually in M97 and
>>> the redirect chain part is in M98. The CLs are large, so I don't really
>>> want to do a merge if I can avoid it. Since the first part of the change
>>> is in M97 I updated the chromestatus entry to indicate that as the release
>>> and added a note that the redirect-chain change is coming in M98. Sorry
>>> for the confusion here.
>>>
>>> Please let me know if there is any concern about this clarification.
>>> Thanks.
>>>
>>> On Thu, Nov 25, 2021 at 1:21 AM Mike West <[email protected]> wrote:
>>>
>>>> LGTM3.
>>>>
>>>> On Wed 24. Nov 2021 at 23:59 Rick Byers <[email protected]> wrote:
>>>>
>>>>> Makes sense, thanks! Arguably almost a bugfix level change. LGTM2
>>>>>
>>>>> On Wed, Nov 24, 2021 at 5:27 PM Ben Kelly <[email protected]>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Nov 24, 2021, 5:07 PM Rick Byers <[email protected]> wrote:
>>>>>>
>>>>>>> Ben, can you speak to the web compat implications (or absence
>>>>>>> thereof) to this change in behavior?
>>>>>>>
>>>>>>
>>>>>> I believe the compat risk should be minimal. This change only
>>>>>> matters for navigation requests and many service workers will be using
>>>>>> nav
>>>>>> preload instead of calling fetch() themselves.
>>>>>>
>>>>>> For sites not using nav preload it's possible they will see changes
>>>>>> in origin headers, sec-fetch-site headers, and SameSite=Strict cookies.
>>>>>> Depending on server logic that could cause requests to be deemed unsafe
>>>>>> by
>>>>>> the server and fail. However, it would match what is done without a
>>>>>> service worker present. Arguably the server wants to make this decision
>>>>>> in
>>>>>> these situations.
>>>>>>
>>>>>> If a site does not want this behavior it requires only a small
>>>>>> service worker change to get previous behavior. They just need to fetch
>>>>>> the url and not the full request. Like `fetch(evt.request.url)` instead
>>>>>> of
>>>>>> `fetch(evt.request)`.
>>>>>>
>>>>>> Nov 24, 2021 at 5:03 PM Chris Harrelson <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> LGTM1
>>>>>>>>
>>>>>>>> On Wed, Nov 24, 2021 at 1:52 PM Ben Kelly <[email protected]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Wed, Nov 24, 2021 at 4:40 PM Ben Kelly <[email protected]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Interoperability and Compatibility
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Gecko: No signal
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I have not filed for formal signals, but we had a TPAC session
>>>>>>>>> <https://github.com/w3c/ServiceWorker/issues/1604> with mozilla
>>>>>>>>> where we reached consensus on these changes.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> WebKit: No signal
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Note, webkit already propagates the origin header. They do not
>>>>>>>>> implement sec-fetch-site or SameSite cookies, so the redirect chain
>>>>>>>>> propagation is not observable or relevant.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>>> Groups "blink-dev" group.
>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>> send an email to [email protected].
>>>>>>>>> To view this discussion on the web visit
>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMjWDoVDeuNnYVuOOS4OjEKrRUkKSt9G9CwT13T_PPS6nQ%40mail.gmail.com
>>>>>>>>>
>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMjWDoVDeuNnYVuOOS4OjEKrRUkKSt9G9CwT13T_PPS6nQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>> --
>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>> Groups "blink-dev" group.
>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>> send an email to [email protected].
>>>>>>>> To view this discussion on the web visit
>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9_ytnSVS4%2BciMFChuTsKEUOC0WJ_0c0-Q3Ue5eyXi8zQ%40mail.gmail.com
>>>>>>>>
>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9_ytnSVS4%2BciMFChuTsKEUOC0WJ_0c0-Q3Ue5eyXi8zQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>> .
>>>>>>>>
>>>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "blink-dev" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to [email protected].
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8_ouG4MC9SkJ-gMDi7vSFYGfw5EvNEbquUcjoCuhLkGw%40mail.gmail.com
>>>>>
>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8_ouG4MC9SkJ-gMDi7vSFYGfw5EvNEbquUcjoCuhLkGw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>> --
>>>> -mike
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMjwXpozc6fkfCfSrhoDxhL_%2B_AT4MZsUAVmJMo-D%3DM2Jg%40mail.gmail.com
>>>
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMjwXpozc6fkfCfSrhoDxhL_%2B_AT4MZsUAVmJMo-D%3DM2Jg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0e761436-ea8e-42fc-85ad-083f5580bdd6n%40chromium.org.
