From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <w.bumiller@proxmox.com>
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 <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; 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 <w.bumiller@proxmox.com>
To: Fabian =?utf-8?Q?Gr=C3=BCnbichler?= <f.gruenbichler@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Jona Draaijer <jcdra1@gmail.com>
Message-ID: <6jguudqs2dyv265k2pp3nxpwc7i7sxxnnh7ad6cm25zqzu6en6@4pnlwhtkyvkm>
References: <mailman.784.1712001709.434.pve-devel@lists.proxmox.com>
<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 <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>
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 <pve-devel@lists.proxmox.com> 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