[pve-devel] [PATCH v3 access-control] add ui capabilities endpoint
t.lamprecht at proxmox.com
Thu Sep 10 10:19:24 CEST 2020
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.
* 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.
More information about the pve-devel