[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