From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id E8B9D1FF136 for ; Mon, 20 Apr 2026 14:27:12 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B8DEE27958; Mon, 20 Apr 2026 14:27:12 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 20 Apr 2026 14:26:39 +0200 Message-Id: From: "Christoph Heiss" To: "Dominik Csapak" , "Lukas Wagner" Subject: Re: [PATCH proxmox/yew-pwt/datacenter-manager/installer v3 00/38] add auto-installer integration X-Mailer: aerc 0.21.0 References: <20260403165437.2166551-1-c.heiss@proxmox.com> <8079685a-be9c-4e28-954c-bd1debe7ce7d@proxmox.com> <52dc9715-66dc-4dc2-a3dc-4216f62f33f2@proxmox.com> In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1776687916285 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.070 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 SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: TAN7I2XKKUCBUKOTSPVWTBSCYHSTRFUA X-Message-ID-Hash: TAN7I2XKKUCBUKOTSPVWTBSCYHSTRFUA X-MailFrom: c.heiss@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pdm-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox Datacenter Manager development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: >> Also, if we add support for generating ISOs in PDM, or display the >> command needed to generate the ISO, we would violate our 'rule' of never >> returning tokens from the API, after they have been initially created, >> that is. > > that is indeed what i meant earlier with the token secrets. > And I don't think we could easily read out the token anyway > as it is hashed.. > > What we could try to do to improve UX is to create the token > on answer file generation (so each answer file has their own > token) and show the token + cli command at once. I really like that idea too + renaming it to secret as said below, *if* we stay with the separate mechanism. Would really simplify the UI, by being able to remove the whole token panel and dialog. And the UX of course too. Since you can also copy configurations with a click, it also wouldn't really be that inconvenient to only one token per configuration. > > If we'd want to create the iso, we'd have to create it in > the same step, as we don't have access to the token anymore later. > >> >> From my point of view, both points can be solved by using distinct >> tokens. The first point is solved by making the new type of token >> unusable in any other context by design. For the second issue, I think >> due to the fact that the token is *only* usable in this context, we >> could afford to return it from the API or as a downloadable ISO, >> assuming the user has high-enough permissions. >> >> What do you think? >> >> Regarding the 'custom token' itself, one thing that we could do is to >> make the token a regular parameter on the POST call, instead of using >> the 'Authorization' header. This would avoid API users from being >> confused about why there is one API route that uses a *different* token >> for no clearly visible reason. This actually was a point I discussed with Aaron early on while fleshing out a rough implementation plan for this. The argument for using the 'Authorization' header was that this header is treated with the required sensitivity (or hopefully, at least) in middlewares such as reverse proxies, i.e. most importantly not logging it somewhere with the whole URL. If we put the token into the URL as a (query?) parameter, there's a good chance it will get logged somewhere. So I'm quite opposed to putting it into the URL.