CODEWITHSUNDEEP
meteor
Zookie
Zookie

Reputation: 87

Proper place to store CustomerID per user account in Meteor

I'm using the accounts-ui package which works great. I need to store additional information for each user account. Things like their CustomerID so I can have multiple users associated with the same Customer. Or maybe isAdmin to flag whether they are an admin user for that Customer or just a normal user.

If there is a simple way to facilitate having multiple user accounts with a Customer and I just haven't seen it, please let me know.

From the docs under Accounts, Meteor.users, the most applicable field would be profile but it also says the following:

profile: an Object which (by default) the user can create and update with any data.

While this is a great place to store things like their first and last name, I would obviously not want the user to be able to modify/update the CustomerID or isAdmin so I'm not sure if this is the best place to store this type of data. Or maybe it is and I should just use a Deny rule so inappropriate users cannot modify this data.

Should I store the CustomerID here or in a separate Customer collection. Or if I'm going about this entirely wrong, I'd appreciate being pointed in the right direction. I noticed the Roles package but that seems to be mostly extending the accounts package and also not storing accounts and roles on a per Customer basis. Also thought about building my own authentication system instead of using accounts-ui which is certainly an option.

Upvotes: 1

Views: 74

Answers (1)

David Weldon
David Weldon

Reputation: 64342

Well it's clear you've done your homework. Here are a few suggestions:

  • If you only have one role type, then the roles package may be overkill.

  • It is safe to use the profile to store role data only if you add a deny rule for updates (see below) As the docs point out, user profiles are currently editable by default even when then insecure package has been removed. I have been lobbying the core devs to change this - so far to no avail.

  • I don't know enough about your data to suggest how to model your customer relationships. You could put an id in the profile, as you suggested, or you could have an array of user ids on the customer objects (you could do something similar with the notion of admins for the customer). It mostly depends on how these documents will be updated/queried/published/etc. Generally I prefer to store only user-specific data in the profile (name, preferences, etc.) and keep the relationships in other collections.

  • In general, I recommend writing your own login UI. It really isn't that hard and in many cases, it's probably a good investment in flexibility for the future.

Meteor.users.deny({
  update: function() {
    return true;
  }
});

Upvotes: 3

Related Questions