[pve-devel] [RFC 1/23] API schema: add 'notoken' property

Tim Marx t.marx at proxmox.com
Tue Oct 22 13:41:16 CEST 2019


Joining a little late into this, but I would vote for an option where we inform the client that this endpoint needs some sort of re-authentication to be accessible, similar to what Thomas already proposed. I discussed this a little bit with Thomas (off-list), but for me the only remaining difference between the api token and the ticket is the fixed expiration, which brings up why we would need both internally, but we didn't find a consent on this for now and as it does not add any immediate value I just mentioned it here for documenting purpose. During our discussion we came up with the idea to inform the user e.g. via mail when a certain action like a ticket creation is performed to mitigate scenarios where a malicious app asks a user for their password (e.g. because the endpoint needs more than a token) and uses it to generate a ticket in the background with all the user privileges while the user still thinks the app has only the restricted subset from the actual api token.


> Thomas Lamprecht <t.lamprecht at proxmox.com> hat am 17. Oktober 2019 17:21 geschrieben:
> 
>  
> On 10/17/19 4:59 PM, Fabian Grünbichler wrote:
> > 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.
> 
> I'd rather have it encoded in the schema, so API docs are annotated,
> also the schematic way to define such things is nicer, if possible.
> 
> Only issue would be if we have to guard API endpoints depending on
> the parameters or their value, but we could naturally still have both
> like now with the permission checks.
> 
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel at pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel




More information about the pve-devel mailing list