Bug 1551798 Comment 12 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to :Ehsan Akhgari from comment #9)
> Thanks Rob.  I think you are right in that we need to store the value of the `SameSite` attribute that was specified by the client.
> 
> Andrea and I chatted about how to do that on IRC today.  He suggested storing the value obtained from the client (either HTTP headers or `document.cookie` in JS) in a separate field of the database and keeping the existing logic which I think is a reasonable decision.

HTTP headers and `document.cookie` are not the only way to create cookies. `nsCookieService::Add` ([via `Services.cookies.add`](https://searchfox.org/mozilla-central/search?q=Services.cookies.add&case=false&regexp=false&path=)) can also create cookies, one of which is part of the API for extensions. Callers should ideally not be concerned about the logic of the `sameSite` calculation. Ideally, when sameSite is left unspecified, the defaults (depending on the pref) should be used. When the caller explicitly chooses the "None" value, sameSite should be forced to "None".

Storing in a separate database column could be useful if you want to migrate all cookies in the future. But it does not seem to be used when the pref is flipped (actually, in the WIP patch it's not read at all). What is the desired behavior when the pref is flipped in either direction?

Is it feasible to only have one member "sameSite" whose "sameSite" lazily becomes Lax or None depending on the preference?

If you want to continue the direction of "sameSiteRaw", could you also allow callers of `Services.cookies.add` to modify this value? (to support the use case of bug 1550032)
(In reply to :Ehsan Akhgari from comment #9)
> Thanks Rob.  I think you are right in that we need to store the value of the `SameSite` attribute that was specified by the client.
> 
> Andrea and I chatted about how to do that on IRC today.  He suggested storing the value obtained from the client (either HTTP headers or `document.cookie` in JS) in a separate field of the database and keeping the existing logic which I think is a reasonable decision.

HTTP headers and `document.cookie` are not the only way to create cookies. `nsCookieService::Add` ([via `Services.cookies.add`](https://searchfox.org/mozilla-central/search?q=Services.cookies.add&case=false&regexp=false&path=)) can also create cookies, one of which is part of the API for extensions. Callers should ideally not be concerned about the logic of the `sameSite` calculation. Ideally, when sameSite is left unspecified, the defaults (depending on the pref) should be used. When the caller explicitly chooses the "None" value, sameSite should be forced to "None".

Storing in a separate database column could be useful if you want to migrate all cookies in the future. But it does not seem to be used when the pref is flipped (actually, in the WIP patch it's not read at all). What is the desired behavior when the pref is flipped in either direction?

Is it feasible to only have one member "sameSite" whose "sameSite" lazily becomes Lax or None depending on the preference? (possibly by introducing a new enum value different from `SAMESITE_NONE`, e.g. `SAMESITE_UNSET`.)

If you want to continue the direction of "rawSameSite", could you also allow callers of `Services.cookies.add` to modify this value? (to support the use case of bug 1550032)

Back to Bug 1551798 Comment 12