From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <pve-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
by lore.proxmox.com (Postfix) with ESMTPS id F2BBD1FF15F
for <inbox@lore.proxmox.com>; Mon, 7 Oct 2024 17:03:01 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id 81B973F980;
Mon, 7 Oct 2024 17:03:25 +0200 (CEST)
From: Dominik Csapak <d.csapak@proxmox.com>
To: pve-devel@lists.proxmox.com
Date: Mon, 7 Oct 2024 17:02:51 +0200
Message-Id: <20241007150251.3295598-1-d.csapak@proxmox.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
X-SPAM-LEVEL: Spam detection results: 0
AWL 0.016 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DMARC_MISSING 0.1 Missing DMARC policy
KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record
SPF_PASS -0.001 SPF: sender matches SPF record
Subject: [pve-devel] [PATCH widget-toolkit] fix external linking to products
by setting cookie SameSite attribute to lax
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: pve-devel-bounces@lists.proxmox.com
Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com>
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(-)
diff --git a/src/Utils.js b/src/Utils.js
index 7dd034a..b68c0f4 100644
--- a/src/Utils.js
+++ b/src/Utils.js
@@ -317,7 +317,7 @@ utilities: {
// that way the cookie gets deleted after the browser window is closed
if (data.ticket) {
Proxmox.CSRFPreventionToken = data.CSRFPreventionToken;
- Ext.util.Cookies.set(Proxmox.Setup.auth_cookie_name, data.ticket, null, '/', null, true, "strict");
+ Ext.util.Cookies.set(Proxmox.Setup.auth_cookie_name, data.ticket, null, '/', null, true, "lax");
}
if (data.token) {
@@ -343,7 +343,7 @@ utilities: {
return;
}
// ExtJS clear is basically the same, but browser may complain if any cookie isn't "secure"
- Ext.util.Cookies.set(Proxmox.Setup.auth_cookie_name, "", new Date(0), null, null, true, "strict");
+ Ext.util.Cookies.set(Proxmox.Setup.auth_cookie_name, "", new Date(0), null, null, true, "lax");
window.localStorage.removeItem("ProxmoxUser");
},
--
2.39.5
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel