How would sorcery handle emails that have "." in different providers

[nsantiago2719]

Microsoft, Yahoo, and Apple treat periods as separate emails, while Google and Facebook treat them as the same.

Example:

Google and Facebook's perspective
[email protected] == [email protected]

Other providers
[email protected] != [email protected]

PS. Sorry @athix it has been more than a year and I haven't made a ticket regarding this issue.

#32 (comment)

[mladenilic]

I personally don't think that Sorcery should do anything about it. Based on Google support post (https://support.google.com/mail/answer/7436150?hl=en), the intention is to reduce the chance that someone mistypes your email address (which is absurd, in my opinion :) ).

Now, when talking about Sorcery, we are talking about authentication – user using its own email address to authenticate with the app. I don't see how it would help to be able to omit dots.

If we are talking about using Google as oauth provider, it would make sense that they would always return the primary email address (with or without dots). In other words, it should always be the same (not sure if this is true, but seems logical).

[joshbuker]

I don't think I understand the ask here. @nsantiago2719, what behavior are you wanting changed?

[nsantiago2719]

@mladenilic, the thing I want to emphasize here is that when a user tries to login using Google oauth provider it is possible that it'll create a new account. For example I already registered a [email protected] now if I tried to login using Google Oauth it'll return my primary email address which is with dot [email protected]. Now sorcery won't be able to authenticate the account because it doesn't exist, it's either it'll create an account or return saying the user is not registered.

Which goes to my suggestion that on create_from(provider) method, if I signin with google oauth it should also consider email address without dots in them. ( I'm not user if it's just google that doesn't care with dots )

[mladenilic]

One thing about create_from and login_from methods – they use uid/provider fields from authentication model to find a user record. This means that if you register using email/password and then try to login with oAuth, login_from will fail to find that user. This is something you have to handle yourself in the controller.

In your use case, even if emails you used during registration and one that google returns are identical, oAuth callback action will still need to handle this, since login_from will not find user record, as it's missing authentication record.

Even if we disregard all this, I feel like Sorcery should stay as simple as possible and just leave it to the developer using it to decide weather they care about Google email policies.

For the argument's sake, you should keep in mind that if you want to support Google emails, it's not just ., it's + as well. Google ignores everything after the + as well, allowing you to have infinitely many email addresses with single account: [email protected] is the same user as [email protected]. Also, there's an exception to the rule, GSuite accounts can use Google's oAuth, but . policy does not apply to them, so you would have to exclude all non-gmail emails that use Google's oAuth. :)

[joshbuker]

Even if we disregard all this, I feel like Sorcery should stay as simple as possible and just leave it to the developer using it to decide weather they care about Google email policies.

This is my current stance as well. This ultimately sounds like an application specific issue, and should be handled as such.

@nsantiago2719, this should be doable using custom validation on the user/authentication, and/or by using the build_from method and handling the creation via your controller. For example, you could add a validation on the authentication that checks if any users have an email that matches using that provider's specific email properties. Then in your controller catch that case and throw them back to the signup form with a specific message. Let me know if you run into any issues, I think adding this to the wiki could be helpful for others as well.

[nsantiago2719]

Thanks for your suggestions. I'll be closing this issue now.