Re: [pve-devel] [PATCH v3 access-control] add ui capabilities endpoint

Re: [pve-devel] [PATCH v3 access-control] add ui capabilities endpoint

[Thomas Lamprecht]

On 06.07.20 14:45, Tim Marx wrote:
> Signed-off-by: Tim Marx <t.marx@proxmox.com>
> ---
> * no changes

Maybe we could merge this into the "/access/permissions" endpoint, maybe with a
"heurisitic" parameter?

> 
>  PVE/API2/AccessControl.pm | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
> 
> diff --git a/PVE/API2/AccessControl.pm b/PVE/API2/AccessControl.pm
> index fd27786..66319cc 100644
> --- a/PVE/API2/AccessControl.pm
> +++ b/PVE/API2/AccessControl.pm
> @@ -718,4 +718,33 @@ __PACKAGE__->register_method({
>  	return $res;
>      }});
> 
> +__PACKAGE__->register_method({
> +    name => 'uicapabilities',
> +    path => 'uicapabilities',
> +    method => 'GET',
> +    description => 'Retrieve user interface capabilities for calling user/token.',
> +    permissions => {
> +	description => "Each user/token is allowed to retrieve their own capabilities.",
> +	user => 'all',
> +    },
> +    parameters => {},
> +    returns => {
> +	type => 'object',
> +	properties => {
> +	    cap => {
> +		type => 'object',
> +		description => 'The user interface capabilities of the calling user/token'
> +	    }
> +	},
> +    },
> +    code => sub {
> +	my ($param) = @_;
> +
> +	my $rpcenv = PVE::RPCEnvironment::get();
> +	my $userid = $rpcenv->get_user();
> +	my $res->{cap} = &$compute_api_permission($rpcenv, $userid);
> +
> +	return $res;
> +    }});
> +
>  1;
> --
> 2.20.1
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel@pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> 

Re: [pve-devel] [PATCH v3 access-control] add ui capabilities endpoint

[Fabian Grünbichler]

On September 9, 2020 9:00 pm, Thomas Lamprecht wrote:
> On 06.07.20 14:45, Tim Marx wrote:
>> Signed-off-by: Tim Marx <t.marx@proxmox.com>
>> ---
>> * no changes
> 
> Maybe we could merge this into the "/access/permissions" endpoint, maybe with a
> "heurisitic" parameter?

IIRC Dominik wanted to slowly replace the caps with permissions anyway, 
the caps are just (still) there because that hasn't happened yet.

I am also not sure whether tokens are a good fit for the regular Web GUI 
- the fact that tickets expire and you are not permanently logged in is 
a feature there IMHO ;)

also, permissions has a return schema already, while it does 'match' 
from a structural point of view (a two-level deep hash), it is something 
altogether different semantically.

TL;DR: iff we really need this, then I'd put it in a separate API call.

>>  PVE/API2/AccessControl.pm | 29 +++++++++++++++++++++++++++++
>>  1 file changed, 29 insertions(+)
>> 
>> diff --git a/PVE/API2/AccessControl.pm b/PVE/API2/AccessControl.pm
>> index fd27786..66319cc 100644
>> --- a/PVE/API2/AccessControl.pm
>> +++ b/PVE/API2/AccessControl.pm
>> @@ -718,4 +718,33 @@ __PACKAGE__->register_method({
>>  	return $res;
>>      }});
>> 
>> +__PACKAGE__->register_method({
>> +    name => 'uicapabilities',
>> +    path => 'uicapabilities',
>> +    method => 'GET',
>> +    description => 'Retrieve user interface capabilities for calling user/token.',
>> +    permissions => {
>> +	description => "Each user/token is allowed to retrieve their own capabilities.",
>> +	user => 'all',
>> +    },
>> +    parameters => {},
>> +    returns => {
>> +	type => 'object',
>> +	properties => {
>> +	    cap => {
>> +		type => 'object',
>> +		description => 'The user interface capabilities of the calling user/token'
>> +	    }
>> +	},
>> +    },
>> +    code => sub {
>> +	my ($param) = @_;
>> +
>> +	my $rpcenv = PVE::RPCEnvironment::get();
>> +	my $userid = $rpcenv->get_user();
>> +	my $res->{cap} = &$compute_api_permission($rpcenv, $userid);
>> +
>> +	return $res;
>> +    }});
>> +
>>  1;
>> --
>> 2.20.1
>> 
>> _______________________________________________
>> pve-devel mailing list
>> pve-devel@pve.proxmox.com
>> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>> 
> 
> 
> 

Re: [pve-devel] [PATCH v3 access-control] add ui capabilities endpoint

[Thomas Lamprecht]

On 10.09.20 10:00, Fabian Grünbichler wrote:
> On September 9, 2020 9:00 pm, Thomas Lamprecht wrote:
>> On 06.07.20 14:45, Tim Marx wrote:
>>> Signed-off-by: Tim Marx <t.marx@proxmox.com>
>>> ---
>>> * no changes
>>
>> Maybe we could merge this into the "/access/permissions" endpoint, maybe with a
>> "heurisitic" parameter?
> 
> IIRC Dominik wanted to slowly replace the caps with permissions anyway, 
> the caps are just (still) there because that hasn't happened yet.
> 

I wanted that too sine a long time ;-) But that did not made it happen yet..

> I am also not sure whether tokens are a good fit for the regular Web GUI 
> - the fact that tickets expire and you are not permanently logged in is 
> a feature there IMHO ;)

nobody forces you to use it, and any user can just do the few modifications
and run the gui with tokens, artificial limits for such things are stupid IMO.

Further:

* and active log-out clears it, so people who use it and want to play safe can
  do so. I mean, on most sites one is logged in for a few hours to even days,
  so if you used a shared or not 100% trusted device you already need to
  actively log out from all relevant sides, independent of they use self-expiring
  tickets, or something else.
* It's effectively not advertised actively, so mostly for debug use for us.

We could show a hint if a token is entered, though.
"Tokes do not automatically expire, you need to actively log out for that."

> also, permissions has a return schema already, while it does 'match' 
> from a structural point of view (a two-level deep hash), it is something 
> altogether different semantically.

as the semantics are actively controlled by the requested via a switch that
does not matters much, IMO. They then actively request another semantic.

> TL;DR: iff we really need this, then I'd put it in a separate API call.
We could also just do the "cap heuristic calculation" in the frontend, using
the full permissions, and fill the Cap object with it.
This avoids a new api call or new multiplexer switch for an existing one but
does not needs to restructure the whole UI cap control, yet.

Re: [pve-devel] [PATCH v3 access-control] add ui capabilities endpoint

[Fabian Grünbichler]

On September 10, 2020 10:19 am, Thomas Lamprecht wrote:
> On 10.09.20 10:00, Fabian Grünbichler wrote:
>> also, permissions has a return schema already, while it does 'match' 
>> from a structural point of view (a two-level deep hash), it is something 
>> altogether different semantically.
> 
> as the semantics are actively controlled by the requested via a switch that
> does not matters much, IMO. They then actively request another semantic.

sure. it's just not very clean ;)

>> TL;DR: iff we really need this, then I'd put it in a separate API call.
> We could also just do the "cap heuristic calculation" in the frontend, using
> the full permissions, and fill the Cap object with it.
> This avoids a new api call or new multiplexer switch for an existing one but
> does not needs to restructure the whole UI cap control, yet.

I think I'd prefer this, should be straight-forward to port from Perl to 
JS.

Re: [pve-devel] [PATCH v3 access-control] add ui capabilities endpoint

[Thomas Lamprecht]

On 10.09.20 10:23, Fabian Grünbichler wrote:
> On September 10, 2020 10:19 am, Thomas Lamprecht wrote:
>> On 10.09.20 10:00, Fabian Grünbichler wrote:
>>> TL;DR: iff we really need this, then I'd put it in a separate API call.
>> We could also just do the "cap heuristic calculation" in the frontend, using
>> the full permissions, and fill the Cap object with it.
>> This avoids a new api call or new multiplexer switch for an existing one but
>> does not needs to restructure the whole UI cap control, yet.
> 
> I think I'd prefer this, should be straight-forward to port from Perl to 
> JS.
> 

A great, a volunteer to do so ;-)