[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 at 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.