* Re: [pve-devel] [PATCH v3 access-control] add ui capabilities endpoint
[not found] <20200706124544.2126341-1-t.marx@proxmox.com>
@ 2020-09-09 19:00 ` Thomas Lamprecht
2020-09-10 8:00 ` Fabian Grünbichler
0 siblings, 1 reply; 5+ messages in thread
From: Thomas Lamprecht @ 2020-09-09 19:00 UTC (permalink / raw)
To: PVE development discussion, Tim Marx
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
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [pve-devel] [PATCH v3 access-control] add ui capabilities endpoint
2020-09-09 19:00 ` [pve-devel] [PATCH v3 access-control] add ui capabilities endpoint Thomas Lamprecht
@ 2020-09-10 8:00 ` Fabian Grünbichler
2020-09-10 8:19 ` Thomas Lamprecht
0 siblings, 1 reply; 5+ messages in thread
From: Fabian Grünbichler @ 2020-09-10 8:00 UTC (permalink / raw)
To: PVE development discussion, Thomas Lamprecht, Tim Marx
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
>>
>
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [pve-devel] [PATCH v3 access-control] add ui capabilities endpoint
2020-09-10 8:00 ` Fabian Grünbichler
@ 2020-09-10 8:19 ` Thomas Lamprecht
2020-09-10 8:23 ` Fabian Grünbichler
0 siblings, 1 reply; 5+ messages in thread
From: Thomas Lamprecht @ 2020-09-10 8:19 UTC (permalink / raw)
To: Fabian Grünbichler, PVE development discussion, Tim Marx
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [pve-devel] [PATCH v3 access-control] add ui capabilities endpoint
2020-09-10 8:19 ` Thomas Lamprecht
@ 2020-09-10 8:23 ` Fabian Grünbichler
2020-09-10 8:28 ` Thomas Lamprecht
0 siblings, 1 reply; 5+ messages in thread
From: Fabian Grünbichler @ 2020-09-10 8:23 UTC (permalink / raw)
To: PVE development discussion, Thomas Lamprecht, Tim Marx
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [pve-devel] [PATCH v3 access-control] add ui capabilities endpoint
2020-09-10 8:23 ` Fabian Grünbichler
@ 2020-09-10 8:28 ` Thomas Lamprecht
0 siblings, 0 replies; 5+ messages in thread
From: Thomas Lamprecht @ 2020-09-10 8:28 UTC (permalink / raw)
To: Fabian Grünbichler, PVE development discussion, Tim Marx
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 ;-)
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-09-10 8:28 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20200706124544.2126341-1-t.marx@proxmox.com>
2020-09-09 19:00 ` [pve-devel] [PATCH v3 access-control] add ui capabilities endpoint Thomas Lamprecht
2020-09-10 8:00 ` Fabian Grünbichler
2020-09-10 8:19 ` Thomas Lamprecht
2020-09-10 8:23 ` Fabian Grünbichler
2020-09-10 8:28 ` Thomas Lamprecht
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox