[pbs-devel] [PATCH proxmox-backup 4/5] fix #3887: api2: add regenerate token endpoint

Thomas Lamprecht t.lamprecht at proxmox.com
Wed Dec 21 14:06:46 CET 2022


On 21/12/2022 11:53, Fabian Grünbichler wrote:
>>> +const TOKEN_SUBDIRS: SubdirMap = &[(
>>> +    "regenerate",
>>> +    &Router::new().post(&API_METHOD_REGENERATE_TOKEN),
>>> +)];
>>> +
>>>  const TOKEN_ITEM_ROUTER: Router = Router::new()
>>>      .get(&API_METHOD_READ_TOKEN)
>>>      .put(&API_METHOD_UPDATE_TOKEN)
>>>      .post(&API_METHOD_GENERATE_TOKEN)
>>> -    .delete(&API_METHOD_DELETE_TOKEN);
>>> +    .delete(&API_METHOD_DELETE_TOKEN)
>>> +    .subdirs(TOKEN_SUBDIRS);
>> hmm, but now I cannot get the available subdir's via GET due to that being
>> already used for reading the token info. Besides the added imperfection, I'm
>> actually not sure from top of my head about the implications in PBS, but in
>> PVE this would cause some technical issues in pvesh/api-viewer - did you
>> check how those (debug api and api-viewer) handle to a shared subdir + "normal"
>> get on the same API endpoint?
> yeah, this would break editing tokens (and external calls to that GET API endpoint).
> 
>>>  
>>>  const TOKEN_ROUTER: Router = Router::new()
>>>      .get(&API_METHOD_LIST_TOKENS)
> it could be folded either into the update_token call (currently no return type,
> could return an optional new secret) or the generate_token call, guarded by a
> new "regenerate" boolean parameter. for updating it could even be combined with
> an actual metadata update, for generate it would probably make more sense to
> enforce that any optional parameters match the current one to avoid accidents..

I'd favor the PUT update one from a REST design POV, as an existing resource
is changed, not a new resource allocated.





More information about the pbs-devel mailing list