Common case.. GROUP_A users can read/write their own documents, but only read other user's documents in that group... GROUP_B can read/write their own documents as well as all documents owned by users in GROUP_A. This is a pretty typical scenario for management chain permissions, but when I've looked ad Meteor and similar solutions it wasn't an option (or incredibly difficult to implement).
You should take a look at the Roles package: https://github.com/alanning/meteor-roles
I recommend taking another look at Meteor's security because although it's different to other platforms, different doesn't mean inferior. It's actually very powerful and simple once you get the hang of it.
Meteor gives you an accounts collection so you don't have to declare it yourself. But we do need to declare the Groups Collection
Groups = new Mongo.Collection('groups');
There is a third Collection needed, documents.
Documents = new Mongo.Collection('documents');
To handle the security for inserting or updating the Documents Collection, you need to set 2 allow rules on the Collection to check if the document.owner is in the user.groups array.
Documents.allow({
insert: function(userId, doc) {
// doc's owner must be one of logged in user's groups
return Meteor.user().groups.indexOf(doc.owner) > -1;
},
update: function(userId, doc, field, modifier) {
return Meteor.user().groups.indexOf(doc.owner) > -1;
}
}
Meteor.publish("documents", function() {
return Documents.find();
};I 'think SQL' all day, or at least a simple subset of it, and I need to learn more. It's paying my bills as a .NET/JavaScipt dev, you know? I'd like to integrate it into my hobby projects. But I'm gonna watch that video linked above and see what it sells me. I certainly don't have any innate resistance to thinking of data as (basically) JSON arrays. I love that. We use that sorta stuff all the time at work, passing data back and forth, to and from the core client JavaScript functions.
I just can't shake the notion that NoSQL is so popular because SQL just is NOT. And I get that: SQL is freaking complicated once you get to the parts that make it so powerful. But maybe that's all a misunderstanding on my part.
It was a big concern at first for me, too. But the platform is so much fun to develop with I decided to start developing with it anyways. Seeing the pace at which things are developing with the platform, and knowing about these non-Mongo data store efforts, I am certain that this won't be a drawback for the platform for very long.
In Mongo, I do the same thing but without an ORM. I declare objects and insert them. If I want relationships between collections I have to declare them myself, but that's just declaring some foreign key fields. I denormalize my data model in some places so I don't have to do that too often, though. And Meteor gives me this interface on the client as well — that along with data reactivity and a pub-sub architecture is a lot of fun to build with.
I've seen a lot of hate for Mongo and I'm not sure why. SQL and NoSQL databases are both capable of doing the same thing, they just have different use cases that they excel at. This video (https://www.youtube.com/watch?v=rRoy6I4gKWU) is the clearest talk I've seen explaining their differences, and having watched that I'm unsure of why people are so rabidly for or against each type of database.