Fix cookie SameSite and Secure policy

[otbutz]

Syncthing currently triggers a warning in the Firefox console because SameSite=None also requires the Secure flag: https://developer.mozilla.org/de/docs/Web/HTTP/Headers/Set-Cookie/SameSite#samesitenone_requires_secure

[calmh]

What's the suggested fix? We currently don't set a samesite policy. Keeping in mind that embedding the Syncthing UI isn't very unusual, and using HTTPS isn't mandatory.

[otbutz]

using HTTPS isn't mandatory

Only SameSite=None requires the Secure attribute. The question is if we can switch to Strict or at least Lax without breaking anything.

We could also set the Secure attribute if it's a secure connection.

[calmh]

As far as I understand it, either of those samesite options breaks embedding the UI in another page, which is a thing that people do. I could be wrong, but the proposed fix should take this into account.

[tomasz1986]

As far as I understand it, either of those samesite options breaks embedding the UI in another page

Could this also have impact on (some of?) the wrappers?

[imsodin]

Related (possibly duplicate): https://github.com/syncthing/syncthing/issues/6927

[otbutz]

Should we add a flag to the config.xml for this? e.g

<gui enabled="true" tls="false" secureContext="true" debugging="false">

I think we can't decide this based on address/tls/insecureAllowFrameLoading flags alone because a reverse proxy might also be involved. IMHO secure by default and optionally permissive is a good design goal here.

[calmh]

Keeping, as I think we'll need to do something here as the default changes in browsers. Step one for whoever tackles it needs to be to figure out what it is we want, precisely. (I feed these headers and policies somewhat confusing.)

[amessina]

The above commit does work properly for the sessionid-* cookie, but the same warning is emitted (by Firefox) for the CSRF-Token-*

Cookie “CSRF-Token-CGJ5O” will be soon rejected because it has the “SameSite” attribute set to “None” or an invalid value, without the “secure” attribute. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite

For those using Apache's ProxyPass, the following works for the sessionid-* cookie.

RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}

[zertrin]

For those using Apache's ProxyPass, the following works for the sessionid-* cookie.

RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}

Thanks a lot, this saved the day as the web interface would suddenly not load.

Not sure why it was working a few weeks ago and not today (might be because of the recent update to Firefox 97 ? Really not sure...)