Closed Bug 1437057 Opened 7 years ago Closed 5 years ago

Expose the origin of a cookie to JS

Categories

(Core :: Networking: Cookies, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
mozilla76
Tracking Status
firefox76 --- fixed

People

(Reporter: miker, Assigned: baku)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged])

Attachments

(2 files)

In order to implement the change in bug 1350812 we need a way we can tell if a cookie has been created using JavaScript or via a network a network request? In our devtools it would be great to have a way to find out. A few notes from bug 1350812: > Doesn't look like we store the source info in the cookie itself, so we'd > have to plumb that through (and properly serialize it to disk, and, and, > and). That info is definitely available when set in the cookie manager (I've > changed code based on that kind of thing before), so it's doable, but we'd > have to be ok with old cookies not having source info until they get > refreshed or removed & recreated. Probably not the end of the world. We are completely fine with it not always being available. Ideally we would have the script URL and line number for cookies created by JS and for Network Cookies we only need the URL. If there is any reason we cannot get that information then a fromNetwork flag or similar would be fine.
Priority: P2 → P3
Whiteboard: [necko-triaged]
(In reply to Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe] from comment #0) > Ideally we would have the script URL and line number for cookies created by > JS And ideally also the column number, so it may be possible to jump to the right place in the code. Sebastian

Is it still needed for devtools?

Flags: needinfo?(odvarko)

I think that it would still be useful to know the location where the cookie was created (source line and URL) - in case it was JavaScript.
This is what we already do for XHRs - showing the source line + URL + stacktrace.

Here is the place where we collect stack-trace info for HTTP requests
https://searchfox.org/mozilla-central/rev/61f224ec08ddc6f9a93ac45c8c3c5f7159be7c2a/devtools/server/actors/network-monitor/stack-trace-collector.js#116-117

We handle: "http-on-opening-request" and "document-on-opening-request"

If we had similar events for cookies (fired synchronously so, we can get the current JS stacktrace) we could use similar concepts.

I see that there is already: http-on-response-set-cookie
https://searchfox.org/mozilla-central/rev/61f224ec08ddc6f9a93ac45c8c3c5f7159be7c2a/netwerk/protocol/http/HttpBaseChannel.cpp#2130

Fired only when a cookie is created due to the presence of Set-Cookie header in the response header of any network request.
(DevTools is not using it yet so, I can't confirm how that works)

Perhaps having http-on-javascript-set-cookie could be used for the case where a cookie is created from JS

Harald, what do you think about this feature-wise?

Honza

Flags: needinfo?(odvarko) → needinfo?(hkirschner)

Cookies could definitely be improved, both when/where cookies were set but also when they got blocked (especially supporting samesize, bug 795346).

Slightly diverging, do we have a http-on-response-set-cookie-like event for blocked cookies?

Flags: needinfo?(hkirschner)

I wrote a patch that exposes a new notification, triggered when document.cookie is set with a valid value.

Subject: the document
Topic: document-set-cookie
Data: the cookie string

Assignee: nobody → amarchesini
Status: NEW → ASSIGNED

Depends on D67589

http-on-response-set-cookie is notified when we process the HTTP Set-Cookie header. We don't throw special notifications when 1 of those cookies is rejected. Lately, I introduced a few new console events about that. If needed we can do something more.

About sameSite cookies, what do you have in mind?

Pushed by amarchesini@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6bd429e30868 Expose the origin of a cookie to JS, r=mayhemer https://hg.mozilla.org/integration/autoland/rev/e22128209b50 Expose the origin of a cookie to JS - tests, r=mayhemer
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla76
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: