This means I don’t want users to have to create a new email address to sign up. It’s a blocker and they would probably never check it for notifications.
I was hoping to set this up in the ‘reddit’ approach where you can have multiple accounts with different usernames but using the same email address.
However, I cannot seem to be able to create accounts using accounts-password with an email address that is attached to another account. Is there a way around it? The key requirement here is that I don’t want to allow a user to try and create a fake account to check if that email address has already been registered.
What I ended up doing is to simply notify the account holder if someone tries to create an account with an email address that is already registered. We removed the requirement that you can have more than one account with the same email address.
The part of uniqueness is clear to me. What is not clear is why it can be ambiguous. If there is a unique username, why can I not reuse email addresses? I don’t just have to roll my own AccountsUI but also will have to rewrite a number of methods from accounts-base eg. to send emails or to allow a user to log in with their email if there is just one that matches.
So before trying to roll my own, I was wondering if someone has already created a fork of accounts-password that can handle this case.
As stated in the docs, you should be able to handle multiple emails for one username.
I’m currently diving more and more in the Meteor community, both in docs and code, so can you provide a simple reproduction of your issue so I could check if the problem is from the docs or if this is a bug ?
My bad, it seems you’re trying to use same emails with two different accounts, which I seem to recall is impossible right now with Meteor.
I will check the code to see if this can overpassed easily
Just checked the code, it is pretty easy to skip the verification for unicity.
However, this may be a problem as there is a function to lookup an user by email in order to process.
In such case, which user should be returned ?
The actual behavior is to return null when case-sensitive duplicates are found, considering the function is designed to return a single user.
This may be overwritten and changed, but it needs to be discussed in a FR on the github repository to be sure there is no backward compatible hole I am not seeing .
If you have some time before you, can you open such request so we can discuss this ?
If not, I suggest you go for your own login flow as this is not supported yet on Meteor accounts-password package
Tracking the email address manually in the collection may be more simple in this case indeed, considering I didn’t find an issue on the meteor repository regarding this matter, which seems to indicate people are using this kind of way or simply not interested in changing the current behavior