Git

• create repo on github named e.g. meteor-scaffolding
• mkdir meteor-scaffolding; cd meteor-scaffolding; gitflowinit
• git remote add origin git@github.com:markusgattol/meteor-scaffolding.git
• git push -u origin develop
• git bsw master; git push —force; git bsw develop
• on Github under settings set default branch from master to develop
• add LICENSE e.g. https://raw.github.com/markusgattol/meteor-scaffolding/develop/LICENSE

Security

• http://pivotallabs.com/meteor-and-web-security/
• separate code into client/server code
• writes: allow/deny rules
• reads: publish/subscribe
• argument checks with audit-argument-checks package
• browser policies with browserpolicy package

Meteor.users.profile

Accounts.onCreateUser( function (options, user) {

user.profile.roles = ["user"]; user.profile.karma = 0; user.profile.online = false;

if ( options.profile ) user.profile = options.profile; return user; });

• add role user and/or group(s) on user creation http://docs.meteor.com/#accounts_createuser
• http://docs.meteor.com/#meteor_users
• http://docs.meteor.com/#accounts_validatenewuser
• https://github.com/alanning/meteor-roles/blob/975f390edb61775190ff9f3b4eba884e2a9ca324/examples/iron-router/server/server.js#L63
• https://github.com/awatson1978/meteor-cookbook/blob/master/cookbook/accounts.md
• http://stackoverflow.com/questions/14535901/how-to-change-profile-name-in-meteor
• http://stackoverflow.com/questions/13660219/meteor-login-with-external-service-how-to-get-profile-information/13870972#13870972
• Meteor.users.update( { _id: Meteor.userId() }, { $set: { "profile.online": true }} );
• Meteor.users.update( { _id: Meteor.userId() }, { $set: { "profile.name": "Carlos" }} );
• Meteor.users.update( { _id: Meteor.userId() }, { $addToSet: { roles: { $each: ['owner', 'user'] }}} );
• Meteor.users.find( { "profile.online": true } );
• Meteor.users.find( { "profile.name": "Carlos" } );

good talking right there! I agree and I will be doing it like this now as I think it's (at least for me) best practice

• hang roles and groups from the user object i.e. user.roles and user.groups
• not put them into user.profile.roles/groups as those are accessible by the user by default
• not have any collections for roles/groups at all because it's not necessary imo (one can always run a query if need be)
• voice the use of user.profiles more as it really is very useful to have all info regarding a user in one place

I also like the profile package https://github.com/BeDifferential/meteor-profile as I think a profile together with roles and groups gets you very far for a majority of use cases out there.

It's also quite interesting the aha effect you get from reading the docs for a second time or third time even, especially when seeing nifty use of it throughout several packages... like for example the use of Accounts.validateNewUser() or Accounts.onCreateUser() are two functions which are incredibly cool once you grasp their power after you "see" all the possible use cases for them :)