Allow deletion of accounts that don't have password

[gagantrivedi]

Describe the bug

Delete accounts asks for passwords, but accounts created using social auth don't have passwords

To Reproduce

Steps to reproduce the behavior:

1. Create an account using google or github
2. Try to delete that account

Expected behavior

Deletion should be allowed

Current workaround

From the login page, follow the reset password workflow to generate a password which can subsequently be used to delete the account.

[Divyansh044]

If this issue is not resolve please assign this to me

[gagantrivedi]

@Divyansh044 I have assigned it to you. Please don't hesitate to bring up any questions or concerns for discussion, whether it's here or on our Discord channel, as you address the issue.

[Divyansh044]

@gagantrivedi Thank you so much for assigning this to me. I would surely ask questions and my concerns.

[Divyansh044]

@gagantrivedi sir I have messaged you on discord regearding my query please reply

[matthewelwell]

@Divyansh044 please post your questions here rather than discord so that anyone from the team can help.

[Divyansh044]

@matthewelwell Sir, I need help in understanding the code base.
second, when i am running the project in localhost it isn't showing signup using google and github options. I am attaching the photos for better explanation

[matthewelwell]

Hi @Divyansh044, to answer your direct question regarding the google auth option not show. That's because you'll need to set up your own flagsmith on flagsmith project and configure the oauth_google flag. See documentation on doing these things here and here respectively.

In terms of understanding the code base, I'm afraid that you'll have to try and do that independently. I can help point you in the right direction at least. Firstly, I'd recommend checking out the PR here #2157 which added the functionality in the first place.

In order to make this change, you'll likely need to check the auth_type attribute that's returned on the GET /api/v1/users/me/ endpoint. This should give you information about what authentication method the user signed up with. Once you have that, you can decide whether or not to show the password entry input.

[shubham-padia]

I'm able to reproduce this issue and would like to work on it, but before that need to clarify the expected behaviour.

For accounts with no passwords, we have the following options:

1. Hide the confirm password section and let the user click the delete button to delete the account.
2. Instead of confirm password, we can have a confirmation similar to how github asks for repos to prevent accidental deletions. That value can be a fixed string like DELETE_MY_ACCOUNT or the user's email. We can have this check on just the frontend side or implement it in the backend endpoint too. IMO we should implement only in the frontend side, because if user is directly using the API, we can assume they know their stuff enough not to accidentally delete their account. But since I don't have clarity on the user behaviour of flagsmith, would love to hear thoughts on this.

Please let me know which approach should be followed and if we follow approach 2, what should be the decisions within that approach should be

[matthewelwell]

Hi @shubham-padia , agree with approach 2 here and let's just implement the check on the FE by prompting them to enter their email.

[shubham-padia]

@matthewelwell One more clarification needed on the approach to solve this:

Right now, the client does not have a way of knowing whether a user has a password set or not, because of which we can't toggle b/w the password and email confirmation dialog. This gives us two options:

1. For Github and Google auth, always ask for the confirmation email FE dialog regardless of whether the password is set or not.
2. Introduce a new field that tells whether the user's password is set or not in the response when the user is fetched, only when explicitly requested by the frontend so that we can toggle b/w password and email confirmation dialog on the frontend. The API endpoint will also make sure that passwordless confirmation is only available to social auth users with no password set. But this will increase the complexity of the task, not by much, but still its an extra field. Also, I'm not sure how much additional benefit password confirmation has over email confirmation on FE. Since you might know the initial context of introducing password confirmation, I'm hoping you might be able to help make a better decision on this

[matthewelwell]

I think option 1 here is fine, thanks for all the thought on this though!

[shubham-padia]

Great! Raised a PR at #3693