Intent to Ship: Propagate request origin and redirect chain in passthrough service workers.

[Ben Kelly]

Contact emails

wande...@chromium.org

Explainer

None

Specification

https://github.com/whatwg/fetch/pull/1345

Summary

This feature will cause service workers that handle navigation requests by calling `fetch(evt.request)` to use the origin and redirect chain from `FetchEvent.request`. Previously this information was always set to the service worker's origin with no redirect chain. This information is used to control the origin header and SameSite cookies sent with the request to the server.

Blink component

Blink>ServiceWorker

TAG review

We did not perform a TAG review as this is a small change to existing specs and we had consensus in the Service Worker Working Group.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

Debuggability

N/A

Is this feature fully tested by web-platform-tests?

Yes

Flag name

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1241188

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5752539724120064

This intent message was generated by Chrome Platform Status.

[Ben Kelly]

On Wed, Nov 24, 2021 at 4:40 PM Ben Kelly <wande...@chromium.org> wrote:

Interoperability and Compatibility

Gecko: No signal

I have not filed for formal signals, but we had a TPAC session 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.

[Chris Harrelson]

LGTM1

--
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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMjWDoVDeuNnYVuOOS4OjEKrRUkKSt9G9CwT13T_PPS6nQ%40mail.gmail.com.

[Rick Byers]

Ben, can you speak to the web compat implications (or absence thereof) to this change in behavior?

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.

[Ben Kelly]

On Wed, Nov 24, 2021, 5:07 PM Rick Byers <rby...@chromium.org> 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)`.

[Rick Byers]

Makes sense, thanks! Arguably almost a bugfix level change. LGTM2

[Mike West]

LGTM3.

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.

--

-mike

[Ben Kelly]

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.

[Joe Medley]

>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? 

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

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.

[Ben Kelly]

On Tue, Nov 30, 2021 at 3:24 PM Joe Medley <jme...@google.com> 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.

[Rafael Santos Silva]

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.

[Ben Kelly]

Please re-test with canary 99.0.4827.0 or later.

For more information see:

https://bugs.chromium.org/p/chromium/issues/detail?id=1286367