Open 6543 opened 2 years ago
I would propose DELETE /user
and add some "save" mechansim like a option in body to say YES ... ?
What's the point of a save mechanism?
The API then will need two requests from those who utilize it. Those that use the API as a front-end wrapper, such as GitNex, could display a "Are you sure" screen for this action ahead of time and avoid having to deal with our save mechanism to show such a screen to the user.
Most use-cases for this API call, will just make the two requests unconditionally, which, if you ask me, is a waste of resources.
also an opinion ...
I agree with @Gusted, a raw API has no need for a confirmation. That is a front-end job.
ok so let it be one request to let them delete all ;)
In fact, wouldn't it be better to have the API mark the user "to be deleted" and delete after X weeks ? This would make revert easier, in case someone account is compromised.
good idea, will require extra work for ALL delete and GET fuctions from models, so i thin it's a own issue (and worth it's own pull)
This would also delete the admin user or should that be not allowed?
Quote from https://github.com/go-gitea/gitea/pull/20410#issuecomment-1197634756
Usually, the web backend and api backend is different. And there were some PRs to decouple the API endpoints from the web. Some backgrounds:
If a function is only used by web UI, then it's not necessary to make it a common API.
So, if a user can only delete themself from the web UI, then function can be written in the web backend code.
If a user can delete themself by API, then I think there need more details: why they need to do so, what's the real use case?
why they need to do so
alternative frontends
why they need to do so
alternative frontends
For which case? Why? Is there anybody would delete their GitHub account by API?
sorry I still dont understand why you are so frighten about such an api ?
Not only me, zeripath also asked similar question. https://github.com/go-gitea/gitea/pull/20410#issuecomment-1192324982 : quote: ARGH ... I am completely unconvinced that this should be an API call. Can you imagine the griefing potentials for self user deletion through API let alone purging?!
.
I think I have explained my views: if there is no real use case to make it an API, it should only exists in web routes. I can not understand why it must be an public API. Everything (especially API part) to be done should have a clear reason. If no clear reason, it might be wrong in the end.
And, the benefit to make it only exits in the web route, it can be easily changed without breaking anything.
Sorry for some comments are off-topic.
More details in
Hmm ... and one more thing:
The web frontend can not call API at the moment. Will you agree my opinion in the #20613?
My opinion is:
sorry I still dont understand why you are so frighten about such an api ?
Sorry that I misunderstood some details, I see the latest reqBasicOrRevProxyAuth
change.
After reading the code reqBasicOrRevProxyAuth
, I have more questions now ....
In the reqBasicOrRevProxyAuth
, if the AuthedMethod
is ReverseProxy
, then the IsBasicAuth and CheckForOTP will be skipped.
Imagine that some users deploy private Gitea instance with ReverseProxy auth mode, does it mean that with this PR, other users can use the token to purge their account?
When many options come together, the problem becomes more complex (back to my first feeling, could the existing web page for "Delete Acount" be enough for daily usage?)
the user should have an api to delete his own account
you just have to look at https://github.com/go-gitea/gitea/blob/a7f0ce620774be861f11b57d426ab59e27e4171a/routers/api/v1/admin/user.go#L307-L320