From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id E4A0C1FF142 for ; Tue, 21 Apr 2026 09:07:54 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 5296F15D9A; Tue, 21 Apr 2026 09:07:53 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 21 Apr 2026 09:07:47 +0200 Message-Id: Subject: Re: [PATCH proxmox/yew-pwt/datacenter-manager/installer v3 00/38] add auto-installer integration From: "Lukas Wagner" To: "Christoph Heiss" , "Dominik Csapak" , "Lukas Wagner" X-Mailer: aerc 0.21.0-0-g5549850facc2-dirty 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: 1776755182947 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.054 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: KHZLNS7W5ZD64IAHFMGPRSCZONMTS75E X-Message-ID-Hash: KHZLNS7W5ZD64IAHFMGPRSCZONMTS75E X-MailFrom: l.wagner@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: On Mon Apr 20, 2026 at 2:26 PM CEST, Christoph Heiss wrote: >>> >>> 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. Good point, that's something I haven't really considered. > > 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. A *query* parameter for a POST request is rather odd, no? As usually any data needed for the request would be put into the request body, either form-encoded or as a JSON body. As far as I'm aware it's not really that common for any kind of logging to log the full request body, but of course that still does not rule it out completely - so your point with regards to using 'Authorization' still stands. With the separate token/secret system it is probably a manageable risk though, so it still *could* be okay to pass the secret in the body.