Openid refresh dance in some sites still broken with Firefox new "SameSite=lax" cookie policy

[Maximiliano Bertacchini]

Session and CSRF cookies switched to explicit "SameSite=None; Secure" in response to the new "lax by default" policy in modern browsers (lp:1888734), but I'm still experiencing intermittent issues while logging in to some sites. My browser is Firefox 81.0 snap on Ubuntu Focal, with "network.cookie.sameSite.laxByDefault: true" (by default) and "app.normandy.startupRolloutPrefs.network.cookie.sameSite.laxByDefault: true". In particular:

- https://snapcraft.io/snaps
    - browser enters an infinite loop redirecting between snapcraft.io and sso/openid, with an infinite number of log messages like: "Cookie “openid_referer” has “SameSite” policy set to “Lax” because it is missing a “SameSite” attribute, and “SameSite=Lax” is the default value for this attribute."

- https://jenkins.ols.canonical.com/online-services
    - Apache returns a 403 page with: "Forbidden: You don't have permission to access /online-services/securityRealm/finishLogin on this server."

Once I manually set "network.cookie.sameSite.laxByDefault: false" at about:config, everything works again. Interestingly, I've been unable to reproduce; but it'll happen every Monday, probably due to session timeout.

I believe setting openid_referer with "SameSite=None; Secure" should fix it, but am a bit unsure as I cannot reproduce at the moment.

[Maximiliano Bertacchini (maxiberta)]

Here's the relevant Firefox experiment: https://bugzilla.mozilla.org/show_bug.cgi?id=1622091

[Experiment] Staged Rollout: Beta rollout of SameSite lax change Fx 79.0 to 81.0 Beta
Start Date: 2020-06-30 End Date: 2020-10-08

[Maximiliano Bertacchini (maxiberta)]

And here's the meta-bug tracking the "sameSite=lax by default" feature: https://bugzilla.mozilla.org/show_bug.cgi?id=1617609

[Maximiliano Bertacchini (maxiberta)]

Ftr, managed to reproduce the issue by deleting all of the affected site's cookies, setting "network.cookie.sameSite.laxPlusPOST.timeout: 0" (from default of 120), then reload.

Setting this timeout to 0 is an admittedly convoluted and artificial procedure, but it points to a timing issue compatible with my experience on Mondays.

[Wouter van Bommel (woutervb)]

As a not for others bumping into this problem.
I could not login this morning on some of the above mentioned sites with the snapped chromium.

Removing the cookies for the related site(s) and the login.ubuntu.com forced me to re-login, but the sites worked from that point on