SimpleSchema for publications and allow/ deny


#1

Is anyone using SimpleSchema for publications or allow/ deny?

It might be cool if one could simply define a schema and would get publications and security for free. In combination with collection2 and autoform it would be much easier to build applications :smiley:

I guess one way might be to add something like insertIf and removeIf to the whole collection and publishIf and updateIf to the fields. Right there one could check for roles, loggedIn, other fields or something else.

I’d like to know what you think about this and how this could be done.
Quite difficult when I think about it but might be worth it :wink:

Edit: I’m especially interested in hearing from @aldeed and @sacha here


#2

If implemented, this would work really well with my REST API package, since it takes into account allow/deny rules. Automatically setting up publications would be even cooler.


#3

I had requested this last year and it was thoroughly discussed, but the idea did not gain much traction

Chime in if you will :smile:


#4

I’m more in favor of allow/deny in schema now than I was when @serkandurusoy suggested it last year, but I still have the same concerns about how complex the edge cases may be.

I created this package for Ongo Works and I typically always use that in place of allow/deny right now. One downside is that it simply wraps allow/deny, so field-level checking is limited to top-level fields (though with some effort, we could probably use the modifier-parsing magic in simple-schema to do deep checking of allowed/disallowed properties based on the update modifier).

I’m currently working on a find pattern with @jperl and @raix, which is getting close to being able to support dynamic publications automatically. That is, client side finds could automatically spin up the necessary reactive subscription, and the selector and fields list coming from the client is validated/whitelisted (which could come from SimpleSchema) to ensure you don’t see anything you’re not supposed to. Like autopublish but with security and minimal, just-in-time data. And on the server you can pass userId as option to limit in the same way.


#5

Actually I recently implemented a similar system for the next version of Telescope. I added an editableBy field to the schema that contains an array of the roles that should be able to edit a property:

https://github.com/TelescopeJS/Telescope/blob/devel/packages/telescope-posts/lib/posts.js#L41-L48

(Note that member means any regular user. But the user still needs to own the document to be able to edit any of its properties.)

I then reuse this property in various places throughout the code. For example, I have a getEditableFields method to get a list of all properties editable by a user, which I then use as Autoform’s fields attributes.

Here’s how I use the editableBy field to make this work:

https://github.com/TelescopeJS/Telescope/blob/devel/packages/telescope-users/lib/permissions.js#L105-L116

It’s not just limited to allow/deny. I also refer to this editableBy field inside my submit/edit methods, to make sure users are not sneaking in properties they’re not supposed to modify.

And just like you said, the next step would be taking care of publications. I already implemented a very limited version of this with a private field. Setting private to true for a Settings property means it will never get published to the client, except for admins:

https://github.com/TelescopeJS/Telescope/blob/devel/packages/telescope-kadira/lib/kadira-settings.js#L14-L27


#6

@aldeed I, too find ongoworks:security's declarative approach and use it in my projects.

My initial request was about providing a context to my schemas. More generally my domain model.

So, actually, it would be awesome if authors of all collection related packages had an agreed upon way to register themselves on a higher order mongo namespace, perhaps through an api provided at meteor core.

It would provide a single context to all things collections, making way for more structured code and programmatic access to all methods and properties of a collection, allowing other package authors do interesting things with them.

For example, I am currently working on a package to collate mongodb sorts by non-en-us locales and I’m kind of stuck at trying to find an elegant way to detect the presence of and integrate with simple schema, collection helpers and collection hooks. I find myself needing much more than mere type/presence checking of the exported objects, but I also need clean ways to enhance them regardless of their order of declaration.