Open Bug 1630773 Opened 5 years ago Updated 4 years ago

source map requests, set-cookie headers not ignored, lax cookies not sent

Categories

(DevTools :: Debugger, defect, P3)

75 Branch
defect

Tracking

(Not tracked)

People

(Reporter: samuel.scheiderich, Unassigned)

References

(Blocks 2 open bugs)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

Setup server to set two cookies, one setup as a standard session cookie (httpOnly, sameSite lax) and connected to a server session. The other cookie is set for the first request for any given session, set to a value stored in the session. This cookie is not httpOnly, nor does it have sameSite set to any value.

Serve an html page, javascript file, and sourcemap file. Html script srced to js file, js file to sourcemap, etc.

Load the page, with js script, with dev tools closed, and with dev tools open.

Actual results:

When loading with dev tools closed, the initial request for the html page correctly has both cookies set as expected, request for JS file (as well as favicon and any other requests) includes cookies as expected, and response does not include set-cookie headers, as expected. If JS prints the cookie value after all requests complete, the expected second cookie value from the first response is printed.

With the dev tools open, the above runs, however an additional request is made for the JavaScript source-map, which is not passed the httpOnly session cookie. The server starts a new session, with the response including both set-cookie headers again. The browser ignores the session cookie (note about this in a second), but the other cookie value is set, and readable in document.cookie.

If you change the second cookie to include sameSite lax, then the browser does not save the value. This also explains the session cookie from the source-map request not being set.

Expected results:

I'm not entirely sure what the correct action here is. Chrome includes the sameSite session cookie in the source-map request, which ties the request with the original request.

If the source-map request is meant to be from a different "origin", then part of the behavior is explained, except that the sameSite lax cookies should still be sent with the request, only "strict" shouldn't be sent. If the source-map request is meant to be treated is being to a different origin, then any set-cookie headers should not set values for the page.

Resetting severity to default of --.

Hi,

I do not have the technical knowledge to replicate this on my end so I will move this over to a component so developers can take a look over it. If is not the correct component please feel free to change it to an appropriate one.

Thanks for the report.

Best regards, Clara.

Component: Untriaged → Networking: Cookies
Product: Firefox → Core

Hi Honza,
Based on comment #0, it seems this is related to dev tools. Could you take a look?
Thanks.

Flags: needinfo?(odvarko)

Logan, this is related to the way how Debugger fetches Source maps.

Perhaps we have this already covered by another report?
Do you know how to reproduce that?

Honza

Component: Networking: Cookies → Debugger
Flags: needinfo?(odvarko) → needinfo?(loganfsmyth)
Product: Core → DevTools

This may be addressed by one overall solution, but I think we should leave this open along with https://bugzilla.mozilla.org/show_bug.cgi?id=1553858 and https://bugzilla.mozilla.org/show_bug.cgi?id=1496986 as other source-map fetch-request issues.

Flags: needinfo?(loganfsmyth)

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Severity: normal → --
Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
See Also: → 1553858, 1496986
You need to log in before you can comment on or make changes to this bug.