Added ability to manually pass an email to handleSignInRedirect()

[ocruzv]

Sometimes getting the email from the redirect URL fails, I think is because the email address arrives parsed in the @ sign, to solve that we could pass manually an email stored locally. Also, that's more secure for the user and it's the recommended way the Firebase people suggest in magic link logins:

https://firebase.google.com/docs/auth/web/email-link-auth#security_concerns

[samuelgozi]

Im adding a method that will allow you to sign in with the oobCode and email directly. However you will be required to extract the oobCode from the email link yourself. Do you think that will be good enough?

[samuelgozi]

The reason I don't want to use local storage is that it is not guaranteed the user will use the link from the same browser, or that the data will be there when he clicks the link. So the method won't be reliable. And using window.prompt will stop the ability to build a custom UI. That's why I'm asking if the solution in the comment above is good enough because it's not a complete solution, it just gives you the building blocks.

I think its a good solution because it allows the devs the flexibility to still do whatever they want, however im open to other ideas.

I also thought about removing the "automatic" email redirect handling from the handleSignInRedirect method because it might clash.

Another solution could be to fix the edge cases in which it doesn't work, but for that, I will need an example of an email link that doesn't work, since I wasn't able to replicate this myself.

please let me know what you think, and sorry for the delayed response!

[ocruzv]

I think we can just extend the current method to make the developer capable of passing the oobCode directly to the method using the same options parameter and make this agnostic of what method the developer chooses to retrieve both the oobCode and email.

In this specific case, I documented an example with localStorage because is easy to implement, but I agree with you that can be a problem if the user opens the email link from a different browser, even, I think the developer should be independent enough to choose the strategy to work with.

Even we can keep the current strategy that consists of extracting the oobCode and email automatically from the redirect query params if the user doesn't pass the oobCode and email as the function params (like I'm doing in the PR).

The main reason of why I created this PR was because we were having problems with the implementation, when we clicked on the email link, the response from the Google Auth endpoint was email is invalid or the email doesn't match with the email in the request or something like that, and when we started passing our own retrieved email (ignoring the parsed one from the redirectUrl) it started to work.

So, what you think? I think the best solution here is to just extend the current method to give the option to the dev to pass an optional param manually defining the oobCode and email, and if the dev doesn't pass any data, then we try to retrieve it from the redirectUrl. We are using it in that way and is working pretty well.

[ocruzv]

That also could be a direct solution to #49

[samuelgozi]

Sounds good. I'll try it out to see how it "feels" to use. And hopefully have an update tomorrow. I like this solution because it doesn't change the API.

[samuelgozi]

Ok, it looks good, and there are no breaking changes. Approved. And thank you very much! I will publish to npm in a few minutes.