Hi Everyone! I’m slightly new to Meteor, and right now I’m trying to build an apps which require a user system more suitable to businesses. I’ve looked around and have not found any articles about this yet. Is there a standard pattern/method to implement roles such as:
- Admin Users for the system
- Company/Manager Users who can invite other users
- Normal users
Could we have meteor accounts-base make users without making sign-up publicly available?
I know this package exists too: https://atmospherejs.com/alanning/roles
Cheers!
Slight edit with resources I’ve found that help with this (but not answer the question about patterns):
4 Likes
Visited the forum to post the exact same question and saw this thread. Thanks for posting this. I think if someone answers this question in database design perspective also, it would be really helpful.
Sorry If I am hijacking your question.
The relevant section of the docs at http://docs.meteor.com/#/full/accounts_config help you with two very important, enterprise-friendly options:
forbidClientAccountCreation Boolean
Calls to createUser from the client will be rejected. In addition, if you are using accounts-ui, the “Create account” link will not be available.
restrictCreationByEmailDomain String or Function
If set to a string, only allows new users if the domain part of their email address matches the string. If set to a function, only allows new users if the function returns true. The function is passed the full email address of the proposed new user. Works with password-based sign-in and external services that expose email addresses (Google, Facebook, GitHub). All existing users still can log in after enabling this option. Example: Accounts.config({ restrictCreationByEmailDomain: ‘school.edu’ }).
Couple this with the roles package from @alanning, you’ll have a good base to craft your accounts system. If you want to go more enterprise you can take a look at
Also, this blog post https://dweldon.silvrback.com/common-mistakes points out common mistakes like unknowingly allowing edits to the profile or publishing secrets.
I also suggest against using the profile field since it is freely editable by the user, unless you use allow/deny rules to prevent it.
From a database design perspective, since role information is not something that changes very often, I guess you can keep it within the user document itself. But if that’s something changing rapidly for you, or you have a really very large roles list, you may consider keeping it within another collection. But I suppose the defaults with the alanning:roles is quite fine.
You also have some other roles package alternatives here https://atmospherejs.com/?q=role
4 Likes
Thansk Serkandurusoy for this fantastic post!