[Discussion][Multi-Site] Future of cookies with SameSite and Secure

[ix5]

As of 2021-01, Firefox 84 warns when hosting isso on a subdomain and accessing cookies.

Repro:

• Isso hosted at comments.example.com
• "Blog" hosted at example.com

Warning:

Cookie “isso-[id]” will be soon rejected because it has the “SameSite” attribute set to “None”. [...]

with a link to MDM SameSite cookies.

Cause:
In isso/views/comments.py, e.g. new() creates a new cookie with SameSite implicitly set to False and Secure implicitly set to None¹.

Possible solutions

1. Isso sets Secure cookie by default. Big problem is that large parts of isso assume that it might be accessed over http, see e.g. the default isso.conf
2. Isso conditionally sets Secure cookie only for https hosts. Ugly but doable.

Help wanted
Would be great if someone who's more involved with web technology could step in and give their ideas and clarify whether my understanding here is even correct.

Footnotes

1. For the full call chain, see the later X-Set-Cookie and the defaults of werkzeug's http.dump_cookie ↩

[Fryboyter]

Big problem is that large parts of isso assume that it might be accessed over http, see e.g. the default isso.conf

According to the documentation, the entry for host with http only exists because of Firefox users who completely suppress the HTTP referer. As far as I know, this must be configured explicitly via about:config.

In my configuration, the entries were previously in reverse order. So first https and then http. There have been no complaints so far. I just tested it and completely removed the http entry from the configuration file. Isso continued to work with Firefox without any problems.

Thanks to Let's Encrypt, more and more pages are only accessible via https. So if the http entry is the only problem (I'm not an expert on SameSite etc.) then I would risk locking out these users in the worst case. Just like users who don't activate Javascript can't use Isso either.

[ix5]

That's my current solution https://github.com/ix5/isso/tree/secure-cookie

[stefangehn]

Since isso can probably not figure out if it's only served over https (and not http) maybe a config option would be the easiest way out, at least for the Secure setting.

For comparison, Gitea has a COOKIE_SECURE setting in its session config that controls this.

[ix5]

I'm wary of adding yet another config option that users have to think about. We should be able to re-use the public-endpoint from the [server] section.

EDIT: Using the value of local.host derived from wsgi.host(request.environ). This even passes through proxies, unless the proxy happens to be stripping request variables.

I've just verified with isso running under supervisord through nginx, and the local.host variable emits https://comments.<mysite.com> as expected. I do not have public-endpoint set.

[stefangehn]

If that works reliable then I would of course also prefer to have no additional options :)

I was just thinking about all the different ways how you can proxy a webapp these days and the (possibly) varying amount of information forwarded to the app (for nginx you usually need to ensure to include uwsgi_params or proxy_params to get a complete set of variables and many examples instead just define a small subset of them, leading to odd results).