Closed Bug 1714542 Opened 3 years ago Closed 3 years ago

network.cookie.sameSite.laxByDefault=true breaks login in


(Core :: Networking: Cookies, defect)




Tracking Status
firefox96 --- disabled


(Reporter: smaug, Unassigned)




(Keywords: regression)

network.cookie.sameSite.laxByDefault=true breaks login in and also in other public sites in Finland.

Regressed by: 1604212
Has Regression Range: --- → yes

I think has been updated. It works now.

Closed: 3 years ago
Resolution: --- → WORKSFORME

Looks like the site is broken again.

Resolution: WORKSFORME → ---

Or, hmm, I'm not sure. On this profile if I have lax enabled, there are issues, but on another FF profile it is fine.

Olli: are you still having problems with the site?

One issue that may affect your test is that cookies set prior to turning on "laxByDefault" are treated as "none by default" (we saved the current interpretation of "no attribute", not that the attribute was unset). If one profile was used to log in before you may have enough cookies that are treated as SameSite=None that it happens to work. I bet if you cleared cookies for that site (and whatever cross-site authentication domains it's using) then the two profiles would behave the same.

Unfortunately I can't test this myself since I don't have a valid authenticator for foreigners. Niklas might, although the site says that as of Jan 13 the German authenticator wasn't working. Have no idea if that's a temporary glitch or something that's going to go on a long time.

Country identifiers that should work include: Italy, Denmark, Estonia, Spain, Croatia, Czech Republic, Slovakia, and Portugal. Sadly not Sweden, which would have been handy because Valentin of the Necko team is based there.

What specific identification method do you use? Since cross-site cookies are the issue it's possible some of them do things better than others. itself seems to use mostly "default" cookies (treated as "none" before, "lax" now). It's got a few explicit "strict" cookies, too.

The log-in button opens, and Firefox doesn't send any cookies to it because all the cookies were just for -- they weren't "" domain cookies. In any case, laxByDefault wouldn't be a problem since this is a navigation. The response does set some important-looking cookies ("OAuth_Token_Request_State") as samesite default (lax/none depending on pref).

The above load does a 302 to which sets some more samesite default cookies. After a second or two this does a POST to which redirects around the same site and ends up on -- all the while setting more default samesite cookies.

I checked a sampling of the individual indentification providers. A lot of them were using explicit SameSite=None cookies, but a couple appeared to use default and would get effective SameSite=Lax cookies with the new Settings. Which provider you specifically use would make a difference.

I can't actually complete the login, but it's possible that if the site then passes the token back to the original site via URL paramenter or through a POST that the lack of SameSite=None cookies on itself isn't the problem.

How does Chrome do on this? I assume it must work, but I don't see how unless the sites involved give different cookies to Chrome.

Flags: needinfo?(bugs)
Severity: -- → S3
Component: Security → Networking: Cookies

It looks like the cookies sent to Chrome by the various providers are the same type as those sent to Firefox (wrt SameSite attributes).

Right now I can login to using this profile which has
network.cookie.sameSite.laxByDefault = true
I use my bank account as the identification method.
I also tested another FF profile and it was fine.

I also tested removing any related cookies, setting the pref to false, login, logout, change the pref to true, and login again, and it was working.

Closed: 3 years ago3 years ago
Resolution: --- → WORKSFORME

I think the needinfo can be cleared here.

Flags: needinfo?(smaug)
You need to log in before you can comment on or make changes to this bug.