meteor Meteor User Accounts Don’t use the default profile field
Example
There’s a tempting existing field called profile that is added by default when a new user registers. This field was historically intended to be used as a scratch pad for user-specific data - maybe their image avatar, name, intro text, etc. Because of this, the profile field on every user is automatically writable by that user from the client. It’s also automatically published to the client for that particular user.
It turns out that having a field writable by default without making that super obvious might not be the best idea. There are many stories of new Meteor developers storing fields such as isAdmin on profile… and then a malicious user can easily set that to true whenever they want, making themselves an admin. Even if you aren’t concerned about this, it isn’t a good idea to let malicious users store arbitrary amounts of data in your database.
Rather than dealing with the specifics of this field, it can be helpful to just ignore its existence entirely. You can safely do that as long as you deny all writes from the client:
// Deny all client-side updates to user documents
Meteor.users.deny({
update() { return true; }
});
Even ignoring the security implications of profile, it isn’t a good idea to put all of your app’s custom data onto one field. Meteor’s data transfer protocol doesn’t do deeply nested diffing of fields, so it’s a good idea to flatten out your objects into many top-level fields on the document.
