-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(api): delete the authenticated user #20410
Conversation
39dc73e
to
e86b42d
Compare
thanks |
8295fbb
to
86ea6a9
Compare
ARGH! I am completely unconvinced that this should be an API call. At the very least this needs to be wrapped in some kind of ARE YOU SURE?! check likely through email confirmation. Can you imagine the griefing potentials for self user deletion through API let alone purging?! This API could be a serious problem. |
I do not have a good feel about this API either. What's the real use case / real user story for such API? |
Hey @zeripath @wxiaoguang, I get where you're coming from and the problems this API might create. As per the discussions in the linked issue (#19439), it seemed clear that for this API there's no point in having the "confirmation" part. That part should be taken care by the frontend. As per my limited knowledge of |
This comment was marked as outdated.
This comment was marked as outdated.
agree but:
|
I have strong objection about making it as a
|
Endpoint: DELETE /user
Check if it fails when user still has ownership of repositories and then verify the use of the purge parameter.
@dhruvmanila would be nice if you merge main, like so ☝️ as each force push do mess up reviewing |
Oh sorry, will keep that in mind from next time 👍 |
Is this ready? |
did add an smal code-format to make it more redable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still have the question why it should be an API, what's the real use case, why a user would call an API to delete themself.
outdated
This comment was marked as outdated.
This comment was marked as outdated.
Hmm, just saw the latest Will the |
return | ||
} | ||
|
||
if err := user_service.DeleteUser(ctx, ctx.Doer, ctx.FormBool("purge")); err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should ensure only site administrator could do it.
Please move the api under |
When this PR mixes with When the instance is running behind reverse-proxy auth, other users with access token (without password/otp auth) can delete the token's user. |
What is the state of this PR? Are you still working on it? |
My opinion is:
I would suggest to clarify the details before continuing. eg: various edge cases, what's the correct approach for auth and account deletion. That's just my opinion, if most maintainers think this is right, I won't block. |
I think I'd agree with you on this. If it brings security risks, I don't think this feature is that much of a benefit that we could ignore this issue. Besides the fact that I don't even really see a reason for such an API endpoint 😆 |
Hey, no I'm currently not working on this. But from all the discussion around this, I think it might be useful to take a step back and see if this is actually beneficial. It's been a while so I've lost context around this 😅 That said, I'm totally fine in closing the PR for the time being and someone can pick it up if we decide to go forward. |
Okay, so let's close this and move the discussion back to the issue |
Delete the authenticated user.
Endpoint:
DELETE /user
resolves: #19439