Fix two sentences the Firefox row made false

Both predate #2222 and both are on master now, so they contradict the table that PR added. One said the header flag keeps a reader signed in in any browser configured to block third-party cookies; the other said the recommended arrangement survives a reload whatever the browser's third-party cookie policy. Firefox's block-all setting is the exception to both, because it discards partitioned cookies as well, and the same table says so three lines away. Folding them in here rather than leaving them to a separate pass, since this branch is already editing the file.
Measure the Safari column on Safari itself
2026-08-24 01:05:03 +01:00 · 2026-08-24 00:06:36 +01:00
1 changed files with 10 additions and 7 deletions
@@ -12,7 +12,7 @@ Unless discussion [#1139](https://github.com/umputun/remark42/discussions/1139)
 Set `ALLOWED_HOSTS="'self',https://example1.org,https://example2.org"` with your domain names, and `AUTH_SEND_JWT_HEADER=true`.
-`AUTH_SEND_JWT_HEADER` is what keeps a reader signed in across a page reload on Safari, in Chrome Incognito, and in any browser configured to block third-party cookies. Read [its security considerations](../../configuration/parameters/#security-considerations-for-authsend-jwt-header) before enabling it: it puts the token in a cookie JavaScript can read, which costs XSS exposure that a server-set `HttpOnly` cookie does not.
+`AUTH_SEND_JWT_HEADER` is what keeps a reader signed in across a page reload on Safari, in Chrome Incognito, and in Chrome configured to block third-party cookies. The one setting it does not survive is Firefox's "block all third-party cookies", which discards partitioned cookies as well, and which no configuration survives. Read [its security considerations](../../configuration/parameters/#security-considerations-for-authsend-jwt-header) before enabling it: it puts the token in a cookie JavaScript can read, which costs XSS exposure that a server-set `HttpOnly` cookie does not.
 **`AUTH_SAME_SITE=none` is not needed alongside it**, which reverses what this page recommended for years, so it is worth showing the measurement instead of asserting it. Signing in anonymously from an embedded widget over https and dumping the browser's cookie jar gives, with the setting:
@@ -46,9 +46,11 @@ Note that this applies to Email, Telegram and anonymous authorisation, which the
 ### What each browser actually does
 Measured on real domains over real certificates, with Remark42 on one registrable domain and the
-host page on another, signing in and then reloading. Every "blocked" column below was verified with
+host page on another, signing in and then reloading. Chrome and Firefox were driven through
-a control cookie: an ordinary third-party cookie written from inside the widget frame has to be
+Playwright, Safari 27 through its own WebDriver, so the Safari column is Safari itself and not an
-dropped, or the run is not blocking anything and proves nothing.
+approximation of it. Every "blocked" column below was verified with a control cookie: an ordinary
 third-party cookie written from inside the widget frame has to be dropped, or the run is not
 blocking anything and proves nothing.
 | configuration | Chrome, default | Chrome, third-party cookies blocked | Firefox, default | Firefox, "block all third-party" | Safari |
 | --- | --- | --- | --- | --- | --- |
@@ -59,8 +61,9 @@ dropped, or the run is not blocking anything and proves nothing.
 Three things in that table are worth spelling out.
 **Safari needs no configuring to break the old recipe.** It blocks third-party cookies out of the
-box, so `AUTH_SAME_SITE=none` on its own has already stopped working there for every reader. This
+box while still honouring `Partitioned`, so `AUTH_SAME_SITE=none` on its own has already stopped
-is not a future deprecation to plan for.
+working there for every reader. This is not a future deprecation to plan for. With the header flag
 the widget's own partitioned cookie is readable in the frame and the session survives the reload.
 **Firefox reaches "works" by a different route, and a weaker one.** Chrome and Safari refuse the
 server's cookie when it carries no `SameSite` attribute, which leaves the field clear for the
@@ -80,4 +83,4 @@ Here are all possible combinations of these two:
 - `ALLOWED_HOSTS` set to a set of domains: comments are shown only on listed domains, and authorisation wouldn't work anywhere, except on the same domain Remark42 is installed on and subdomains of it.
 - `AUTH_SAME_SITE` set to `None`: comments are shown on any domain. Authorisation works on browsers that still permit third-party cookies, and stops working on the ones that block them.
 - `ALLOWED_HOSTS` set to a set of domains and `AUTH_SAME_SITE` set to `None`: comments are shown on listed domains, with the same authorisation caveat.
- `ALLOWED_HOSTS` and `AUTH_SEND_JWT_HEADER=true`, with `AUTH_SAME_SITE` left alone: comments are shown on listed domains, and Email, Telegram and anonymous authorisation survives a reload whatever the browser's third-party cookie policy. This is the recommended arrangement. Adding `AUTH_SAME_SITE=none` on top changes nothing about whether a reader stays signed in; it only adds the server's unpartitioned cookies where the browser still takes them.
+- `ALLOWED_HOSTS` and `AUTH_SEND_JWT_HEADER=true`, with `AUTH_SAME_SITE` left alone: comments are shown on listed domains, and Email, Telegram and anonymous authorisation survives a reload under every third-party cookie policy except Firefox's "block all third-party cookies", which no configuration survives. This is the recommended arrangement. Adding `AUTH_SAME_SITE=none` on top changes nothing about whether a reader stays signed in; it only adds the server's unpartitioned cookies where the browser still takes them.