[pve-devel] [RFC 1/23] API schema: add 'notoken' property

Fabian Grünbichler f.gruenbichler at proxmox.com
Thu Oct 17 16:59:48 CEST 2019


On October 17, 2019 4:46 pm, Thomas Lamprecht wrote:
> On 10/17/19 3:13 PM, Fabian Grünbichler wrote:
>> to mark API methods which should not be available to clients authenticated using an API token
> 
> please wrap lines, for commit messages it's common to use << 70 as limit,
> at least <= 80 would be really great.

indeed. that sometimes happens to slip through when I compose the 
message directly with -m "..." -m "..." ;)

> 
>> 
>> Signed-off-by: Fabian Grünbichler <f.gruenbichler at proxmox.com>
>> ---
>> 
>> Notes:
>>     if applied, any users of this need corresponding versioned depends.
>> 
>>  src/PVE/JSONSchema.pm | 5 +++++
>>  1 file changed, 5 insertions(+)
>> 
>> diff --git a/src/PVE/JSONSchema.pm b/src/PVE/JSONSchema.pm
>> index db38d44..a42d814 100644
>> --- a/src/PVE/JSONSchema.pm
>> +++ b/src/PVE/JSONSchema.pm
>> @@ -1263,6 +1263,11 @@ my $method_schema = {
>>  	    description => "Method needs special privileges - only pvedaemon can execute it",
>>  	    optional => 1,
>>          },
>> +	notoken => {
> 
> IMO slightly to general. Also, negative named properties are not ideal, even
> if I sometimes use them too, Dominik always notices it in the web ui ;)
> 
> The question is, do we want to have certain API endpoints which we straight
> forbid, or do we want some which can only be called by sending along the full
> user credentials.
> 
> The latter would allow to only use an API token for a mobile app (for example),
> but still have a password change dialog there, with allows to change the
> password of the user which the token belongs, but only if the current password
> is sent along and without some hacks required by the app where it temporarily
> requests a "full user ticket". (how TFA would play into something like this is
> another question...)
> 
> I mean, just an example, but we could then resort to name it something like
> "require-fullauth"
> 
> or we reverse the default and name it:
> "token-auth-sufficient"
> 
> anyway, bike-shedding details, but for an RFC OK I hope ;P

sure - I don't care about the name at all, and a positively-named option 
with a default of 1 is also okay :)

I am not sure whether we even really need such a schema option - we 
could also just have a helper in PVE::RPCEnvironment or 
PVE::AccessControl and call that directly at the start of the API 
methods. in the end, it probably comes down to how many such API methods 
there are.

> 
>> +	    type => 'boolean',
>> +	    description => "Method is not available for clients authenticated using an API token.",
>> +	    optional => 1,
>> +	},
>>          download => {
>>              type => 'boolean',
>>  	    description => "Method downloads the file content (filename is the return value of the method).",
>> 
> 
> 
> 




More information about the pve-devel mailing list