Skip to content
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

Don't sign-in automatically on sign-up #21

Open
fidelix opened this issue May 14, 2020 · 3 comments
Open

Don't sign-in automatically on sign-up #21

fidelix opened this issue May 14, 2020 · 3 comments

Comments

@fidelix
Copy link

fidelix commented May 14, 2020

signUp([email], [password])
Signs up with email and password or anonymously when no arguments are passed.
Automatically signs the user in on completion.

It's better to let the developer customise that, just like google's API.
With this design, you are taking my choice away and I have to manually sign the user out (I want e-mail confirmations before doing anything).

@samuelgozi
Copy link
Owner

Hi, and thanks for opening a new issue.
There are multiple reasons for this, and it's not only in this library, google does this too.

The first reason is that when creating an anonymous account, if the user is not signed in immediately, then the account is lost, and cannot be recovered again(because it's anonymous).

Another reason is that Google internally uses the same endpoint for both, anonymous and email(called password accounts internally) accounts, so when using either, google will create an account and send us back the credentials in the response.

Now, even if the user itself didn't validate their email, the account is still created. So I recommend showing a UI element telling the user that they must validate the email before being able to use full functionality of the app. You can check that by looking at the user.emailVerified property.

However I do believe that we should provide a way to overwrite this, so I'm leaving this issue open until I implement a solution.

@fidelix
Copy link
Author

fidelix commented May 14, 2020

That makes perfect sense.
If the original API does this, then perhaps you should indeed close this issue.

Thanks a ton for responding thoroughly.

@samuelgozi
Copy link
Owner

samuelgozi commented May 14, 2020

I like to take time to decide such things. Thats why I'm leaving this open.
I do agree that we should at least give developers the option, so I'm pretty sure I'll implement this. Even if it's just a third argument that could be a boolean.

And also, I try to never let the fact that Firebase does something in a certainty dictate if it's a good idea or not. In my opinion they made a lot of mistakes, so its okay, and even welcome to question everything.

And thank you for taking the time to look into this, and open an issue. Feedback is what makes the libs better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants