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.gruenbich...@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).",
>>
>
>
>
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
