I’ve got a situation where we need to have multiple accounts using the same email address. I’ve tried removing the unique attribute from emails on the database but I’m still getting the error that the email is not unique when creating new users. This would mean we need to deactivate logging in with emails and making login only work with unique usernames.
We have a business case where we really need to make this work. Does anyone have a recommended approach to how to solve this?
I don’t understand. Could you explain your use case a bit better? If you need have multiple accounts with same email address, and you were going to use the email for login, how would that work? How would you be expected to identify the user? If you don’t need to identify the user by email (i.e., login via the email), then couldn’t you just use username for login and have a separate field (other than the emails array) to keep the email address of the user?
Sorry, I might have been unclear in my initial explanation. What I want to do is only login with usernames and not emails. Users will be identified with their unique username and multiple users will have the same email.
We have a case where our clients share a department email and they do not do business using personal emails. They do not want to use our service if they are forced to use personal emails.
So, I’m exploring the possibility of removing the unique requirement of emails and only use them for communication and deactivate using emails to login.
Edit: Regarding your proposal, how would this affect “Forgot password” and other built in functions for retrieving notifications from the application? Would we have to recreate all these services?
How about storing the email in a new field instead of the one used by Accounts ? If you’re not using emails to login users, none of the methods (addEmail, removeEmail…) are really relevant, and they all prevent duplicates so that the emails field can be used to login.
Just create a new email field and use regular mongo updates on them when needed ?
Edit : just noticed someone said the said thing… So, for forgotPassword, you pass the email explicitly when calling it anyway, so it doesn’t matter where it’s stored. Other methods, like sendResetPasswordEmail, ask that the email is contained in the emails field, so that would not work with the solution we’ve given. Not sure you have a choice though, the unique emails thing seems built-in the Accounts package…
Can’t you not just create some e-mail aliases (might even be on your own domain) like: client+user@somedomain.com which you just forward to: department@client.com?
That way you don’t need to change infrastructure and they can all login with a custom (but fake) e-mail. Only thing you would need to do is to add some aliases. You could even pre-generate them numbered and deliver them an Excel list.
That does make sense. It could be a viable work around. I’m just concerned about this feeling like a “hack” instead of a recommended work around since I’m circumventing the core features for the emails field.
What I could do is have a “notifications email” property. And when a email is missing it checks for this instead.
The system we’re building needs to be able to handle the users with minimal interaction. This will create a bottleneck for on-boarding so our client isn’t too happy about that.
Doesn’t anybody else have this issue? Wouldn’t Meteor have a viable business workaround for something like this? Our clients clients are typically an older generation of businesses and they seem to be non-technical. So it seems they are used to not having to work with individual emails.
Well the problem is that you cannot do this securely. And that’s what account systems are made for.
For example with a shared e-mail you cannot:
What I do find interesting is that it seems to be of real business value for your customers. That might be interesting to invest in as a feature which is a unique advantage to your app! As I expect most apps don’t offer this at all.
I do think you would need to work out those security matters in a solid way.
Yes, I agree.
I was hoping to find others that might have had the same case and would have insight in requirements etc. But I guess the answer right now is that the only way to do this is by creating an additional property for notification emails and then using that while accepting the risk that the accounts will be vulnerable.
Don’t get it. What would make the accounts vulnerable?
The reason that you keep seeing this issue after you remove the index from the DB is that the Accounts package recreates it every time the app starts up if it doesn’t exist by calling users._ensureIndex('emails.address', {unique: 1, sparse: 1});
You can of course clone package into your packages directory for you app, or set the path to another directory on your system which contains the packages by setting the METEOR_PACKAGE_DIRS environment variable, and then make any changes necessary to make them work they way you need.