From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 0D6E190480 for ; Tue, 2 Apr 2024 10:00:59 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E5A6AE9 for ; Tue, 2 Apr 2024 10:00:58 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Tue, 2 Apr 2024 10:00:55 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 061604481B; Tue, 2 Apr 2024 10:00:55 +0200 (CEST) Date: Tue, 2 Apr 2024 10:00:54 +0200 From: Wolfgang Bumiller To: Fabian =?utf-8?Q?Gr=C3=BCnbichler?= Cc: Proxmox VE development discussion , Jona Draaijer Message-ID: <6jguudqs2dyv265k2pp3nxpwc7i7sxxnnh7ad6cm25zqzu6en6@4pnlwhtkyvkm> References: <491134625.3322.1712042877345@webmail.proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <491134625.3322.1712042877345@webmail.proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.037 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 POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [json-schema.org] Subject: Re: [pve-devel] GET /access/users/{userid} has parameter 'tokens' with 'additionalProperties' containing object definition X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2024 08:00:59 -0000 On Tue, Apr 02, 2024 at 09:27:57AM +0200, Fabian Grünbichler wrote: > > > Jona Draaijer via pve-devel hat am 01.04.2024 22:00 CEST geschrieben: > > Hi, > > > > As per the title, that endpoint has an additionalProperties value that is > > not a bool, but rather an object definition. (It's defined in > > pve-access-control/src/PVE/API2/User.pm). > > > > As far as I can tell, all other 'additionalProperties' are bools. Does > > anyone know why this specific one is different, or if this difference is > > intentional? > > I think this was just an accident. > > > From the looks of it it seems like it's used as a "we need this standard > > option, but also have to make it optional". I am still quite new to perl, > > so I don't know if there is a way to do what was intended. > > My guess is the intent was to have > > tokens => get_standard_option('token-info', { optional => 1 }), > > instead, @Wolfgang? The `token-info` standard option defines the structure of a single token, which is a hash containing `expire`, `privsep` and `comment`. If we map `tokens` to that, then `tokens` would be exactly one token. The returned `tokens` value is a hash mapping token names to their info, like: "tokens" : { "first" : { "expire" : 0, "privsep" : 1 }, "second" : { "expire" : 0, "privsep" : 1 } } So, each value inside the `tokens` object has the `token-info` schema. Most other API calls seem to return an array with the id merged into it as "tokenid", but this call did it this way from the beginning... But yes, we don't *usually* do this, but our JSON schema validator supported this and the API call was added like this originally, so declaring its schema this way was easier. You can see the definition in the JSON schema spec[1]. Note that `true` and `false` are not explicitly mentioned there, as these values are themselves considered schemas that "produce themselves as assertion results"[2]. Also note that our schema isn't fully compliant with the spec (for instance we declare required vs optional fields differently), but at least feature-wise we do try to stick to keeping it a subset of it (with the occasional weirdness-extension to deal with legacy cruft such as how you can use the *value* of the *model* property as a *key* to declare the mac address in a network interface for a VM's network device... please don't :-) ) [1] https://json-schema.org/draft/2020-12/json-schema-core#section-10.3.2.3 [2] https://json-schema.org/draft/2020-12/json-schema-core#section-4.3.2