You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am trying to disable access to a Quetz server for "old" users. We are using azuread as the only authentication provider so these users should not be able to authenticate without a valid company Azure/Office account.
However existing API keys linked to these accounts still work. Therefore I want to remove all API keys for these accounts.
So far I have done this with a DELETE /api/users/{username} which removes the Identity, Profile, and API keys:
The problem with this method is that quetz-frontend requires Profile data to display the details of the uploader of a package/version. The result is that the page will not load and display an error for package version uploaded by a user that was deleted using this method.
Is there an alternative (existing) way of doing this?
I was thinking that adding an optional user parameter to the GET /api/api-keys resource could work. This would give me a list of keys to then delete.
The text was updated successfully, but these errors were encountered:
Hi!
I am trying to disable access to a Quetz server for "old" users. We are using
azuread
as the only authentication provider so these users should not be able to authenticate without a valid company Azure/Office account.However existing API keys linked to these accounts still work. Therefore I want to remove all API keys for these accounts.
So far I have done this with a
DELETE /api/users/{username}
which removes the Identity, Profile, and API keys:quetz/quetz/dao.py
Lines 233 to 241 in 56ab2cf
The problem with this method is that quetz-frontend requires
Profile
data to display the details of the uploader of a package/version. The result is that the page will not load and display an error for package version uploaded by a user that was deleted using this method.Is there an alternative (existing) way of doing this?
I was thinking that adding an optional
user
parameter to theGET /api/api-keys
resource could work. This would give me a list of keys to then delete.The text was updated successfully, but these errors were encountered: