From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Dominik Csapak <d.csapak@proxmox.com>
Subject: [pve-devel] applied: [PATCH widget-toolkit] fix external linking to products by setting cookie SameSite attribute to lax
Date: Tue, 15 Oct 2024 15:30:39 +0200 [thread overview]
Message-ID: <03cf9487-37a8-4f87-8dee-1ea63d86ffbb@proxmox.com> (raw)
In-Reply-To: <20241007150251.3295598-1-d.csapak@proxmox.com>
Am 07/10/2024 um 17:02 schrieb Dominik Csapak:
> We introduced the 'strict' setting when browsers warned about our
> cookies not having any SameSite setting [0]
>
> While this works in general, it had an unforeseen side effect:
>
> When linking to a URL of our products, the cookie does not get sent on
> the initial page load, leading to the username/CSRFPreventionToken not
> being set in the index response.
>
> Our UI code interprets this as being logged out (e.g. because the ticket
> is not valid) and clears the cookie, displaying the login window.
>
> The MDN reference[1] says that setting it to 'lax' is similar to
> 'strict', but sends the cookie when navigating *to* our origin even from
> other sites, which is what we want when linking from elsewhere. (This
> would have also been the default if we wouldn't have set any attribute).
>
> 0: https://lore.proxmox.com/pve-devel/20230315162630.289768-1-m.carrara@proxmox.com/
> 1: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#SameSite_attribute
>
> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
> ---
> Alternatively, we could try to modify the client code to retry with the
> content of the cookie (which the client still has), to generate a
> ticket. Though I'm not sure that will work correctly, since I observed
> some even stricter behaviour in Firefox ESR, where not only the
> navigation part did not send the cookie, but also subsequent requests
> did not do that (I did not test for long, so this may have been an
> artifact of a different issue).
>
> I'd generally prefer this solution, since it's less intrusive and
> restores the behaviour we had before the change, altough I'm not against
> implementing a retry in the client code if that's preferred.
>
> src/Utils.js | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>
applied, with slight rewording of the commit message (I initially interpreted
"URL of our products" as a URL to a www.proxmox.com product page, which confused
me for a bit), thanks!
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
prev parent reply other threads:[~2024-10-15 13:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-07 15:02 [pve-devel] " Dominik Csapak
2024-10-08 12:10 ` Max Carrara
2024-10-14 11:57 ` Dominik Csapak
2024-10-14 12:03 ` Dominik Csapak
2024-10-15 13:30 ` Thomas Lamprecht [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=03cf9487-37a8-4f87-8dee-1ea63d86ffbb@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=d.csapak@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal