From: "Shannon Sterz" <s.sterz@proxmox.com>
To: "Thomas Lamprecht" <t.lamprecht@proxmox.com>
Cc: Thomas Lamprecht <t.lamprecht@proxmox.com>,
Yew framework devel list at Proxmox <yew-devel@lists.proxmox.com>
Subject: Re: [yew-devel] [PATCH yew-comp] http wasm client: load csrf token from global Proxmox object
Date: Wed, 17 Dec 2025 08:58:48 +0100 [thread overview]
Message-ID: <DF0BZCBPNRO1.LVCIIMF4NK9K@proxmox.com> (raw)
In-Reply-To: <48d9670d-32da-4c5e-a4a2-46e15dd93c03@proxmox.com>
On Tue Dec 16, 2025 at 5:53 PM CET, Thomas Lamprecht wrote:
> Am 10.12.25 um 14:50 schrieb Shannon Sterz:
>> previously csrf tokens were only loaded from session storage. this
>> could lead to two scenarios:
>>
>> - the csrf token expired while the newer authentication ticket was
>> still valid.
>> - when restoring a session, session cookies were restored, but session
>> storage seemingly isn't always restored (tested in chromium and ff).
>> this lead to no csrf token being loaded here, the
>> `unwrap_or_default()` would then return the empty string as a csrf
>> token.
>>
>> both scenarios would lead to a situation where a valid authentication
>> cookie was present, but the csrf token was empty or expired. the
>> result is that all GET requests would work properly, as we don't check
>> csrf tokens there. however, the first non-GET request would lead to a
>> logout.
>>
>> to fix this, we first load the token from the Proxmox object that is
>> injected via a script in the index.html for all proxmox products. we
>> prefer this token over the one in session storage.
>> authentication_from_cookie (that calls the extract_auth_from_cookie
>> function), is and should only be called when the page was just loaded.
>> so the csrf token in the Proxmox object will always be fresher than the
>> one in the session storage.
>>
>> additionally, if no csrf token can be found, return None to trigger a
>> fresh log in.
>
> Many thanks for this patch, the basic approach checks out AFAICT, some
> comment w.r.t. (pre-existing) code structure inline though.
>
>
>> Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
>> ---
>>
>> tested this by opening and closing chromium and firefox after logging in
>> with active session restore. without this patch an empty csrf token
>> would be loaded (and then persisted to session storage).
>>
>> note, i intentionally did not put this in load_csrf_token() in lib.rs as
>> that could break the assumption that it will always return the same
>> token last stored with store_csrf_token().
>>
>> src/http_client_wasm.rs | 14 ++++++++++++--
>> 1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/http_client_wasm.rs b/src/http_client_wasm.rs
>> index 25d0dd2..ae99a99 100644
>> --- a/src/http_client_wasm.rs
>> +++ b/src/http_client_wasm.rs
>> @@ -3,9 +3,11 @@ use std::pin::Pin;
>> use std::rc::Rc;
>> use std::sync::Mutex;
>>
>> +use js_sys::Reflect;
>> use percent_encoding::percent_decode_str;
>> use serde::Serialize;
>> use serde_json::Value;
>> +use wasm_bindgen::JsValue;
>>
>> use proxmox_client::{Error, HttpApiClient, HttpApiResponse, HttpApiResponseStream};
>> use proxmox_login::{Authentication, Login, Ticket, TicketResult};
>> @@ -55,8 +57,16 @@ fn extract_auth_from_cookie(project: &dyn ProjectInfo) -> Option<(String, String
>> if key == name {
>> let items: Vec<&str> = value.split(':').take(2).collect();
>> if prefixes.contains(&items[0]) {
>> - let csrf_token = crate::load_csrf_token().unwrap_or_default();
>> - return Some((value.to_string(), csrf_token));
>
> Might be nice to have a comment here, like:
>
> // prefer the token from the index template's JS object, which is the most
> // recent one, fallback to the one from the session storage (possibly outdated)
>
> That said, I wonder if the function should be split into one to get the ticket and one to
> get the CSRF token which then could be called separately in authentication_from_cookie
> as this already feels like two different functions to me, it was just slightly hidden
> by the csrf extraction being just a short call to another fn previously.
>
> This doesn't mean you have to put it in the lib's load_csrf_token though, can be a
> helper local to this module with a short doc-comment describing the background.
sure we can do that, i thought keeping it as one was easier since this
is a private helper function. but yeah two helper functions that are
called separately is definitively cleaner, will send a v2. thanks!
>> + let window = gloo_utils::window();
>> + if let Ok(proxmox) = Reflect::get(&window, &JsValue::from_str("Proxmox")) {
>> + if let Ok(token) =
>> + Reflect::get(&proxmox, &JsValue::from_str("CSRFPreventionToken"))
>> + {
>> + return token.as_string().map(|t| (value.to_string(), t));
>> + }
>> + }
>> +
>> + return crate::load_csrf_token().map(|t| (value.to_string(), t));
>> }
>> }
>> }
>> --
>> 2.47.3
_______________________________________________
yew-devel mailing list
yew-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/yew-devel
next prev parent reply other threads:[~2025-12-17 7:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-10 13:50 Shannon Sterz
2025-12-16 16:53 ` Thomas Lamprecht
2025-12-17 7:58 ` Shannon Sterz [this message]
2025-12-17 14:27 ` [yew-devel] Superseded: " Shannon Sterz
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=DF0BZCBPNRO1.LVCIIMF4NK9K@proxmox.com \
--to=s.sterz@proxmox.com \
--cc=t.lamprecht@proxmox.com \
--cc=yew-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox