Proof that no one uses Allow/Deny

[streemo]

• Actually, I use allow/deny
• I don’t have a single Allow/Deny call in my entire project

Show results

[sashko]

Well, we are doing everything in our power to stop people:

1. It has never been in the tutorial
2. The guide explicitly tells you not to use it

So really to discover it you would have to read some old books, or find it in the docs. Maybe that means it’s time to deprecate officially!

[streemo]

I created this thread half as a joke, half out of curiosity.

I feel like the main use case of allow/deny is for clients who are given DB access. Then it makes sense to scope their queries with allow/deny and just let them use the client-side mongo api.

Otherwise, I guess explicit > implicit …

[sashko]

As an added bonus, Meteor methods are essentially isomorphic to GraphQL mutations, which makes life very easy for Apollo :]

[awatson1978]

@streemo

I feel like the main use case of allow/deny is for clients who are given DB access. Then it makes sense to scope their queries with allow/deny and just let them use the client-side mongo api.

There’s a database term for this: prefetching. Was a common pattern with larger Oracle database clusters that have oracle running on the think clients. allow/deny could conceivably be extracted into Prefetch.allow() and Prefetch.deny()

[sashko]

I’m not sure what it has to do with pre fetching? Since allow and deny only operate on writes, not reads?

[awatson1978]

You can set allow/deny rules on the fetch parameter, along with insert, update, and delete.

fetch outweighs all the other rules by an order of magnitude in terms of use, so it’s set true by default; and almost nobody ever thinks of going in and modifying it. We’ve used it as a hook for fine-grained HIPAA audit logging in the past (circa 0.7 days, maybe?). Haven’t used it in awhile though.

And maybe the Prefetch namespace isn’t the perfect name for it to fall under. But in Oracle world, the “prefetch” functionality was something similar to minimono + livedata + allow/deny + otherstuff.

Maybe DataThrottle.allow() and DataThrottle.deny()?

[trajano]

It’s in the Angular-Meteor tutorial

Step 8.6: Add allow logic to the model

What’s the recommendation now? I kind of liked having a check like this

// Simple checks to ensure that the user is logged in before making changes.
Tasks.allow({
  insert: (userId, doc) => !!userId,
  update: (userId, doc, fields, modifier) => !!userId,
  remove: (userId, doc) => !!userId
})

[sashko]

The recommendation is to use ValidatedMethod and you can use a mixin to ensure login: https://github.com/meteor/validated-method#community-mixins

It’s quite unfortunate that the Angular-Meteor tutorial uses that feature.

[trajano]

I presume we still need to do a .deny or is it deny by default now? At least I can make the adjustments to boilerplate to remove it.

[sashko]

You can use deny just in case to make sure no other code or package calls allow. But by default client writes are denied. See here: http://guide.meteor.com/security.html#allow-deny

I got like 90% of the way to making allow-deny completely removable from Meteor, but never quite finished it.

[streemo]

Wow – nice. I didn’t think to use deny in order to prevent other packages from using allow. It’s a bit poetic – using allow/deny api so that you don’t use it… And you should totally finish that

[raskal]

Server Allow / Client Deny for same Collection Operation

Please take a look at the following code. Is it possible to allow an insert from server code and deny the same from client code ? This is intended to stop an insert from being entered via the browser, whereas the same would execute if it is placed in a meteor directory that is not client or server. The following code anyway inserts the record twice, so not my expected behaviour. //------------- test code below // the following code runs on both server and client nameValuePair = new Mongo.Col…

@sashko pls take a look at the other thread.

I think allow/deny can make it very elegant to write isomorphic code, but since the current behavior is only server specific it is therefore not really useful.

In reality, it is Meteor.methods that should be deprecated because it really is just the same old client/server pattern.

[sashko]

Note that allow/deny is actually implemented on top of methods, so it is a strictly less powerful pattern.

[streemo]

I strongly disagree.

When you want a finite amount of things from an infinite set.

Choosing what you want out of an infinite set of patterns is far more convenient than choosing what you don’t want out of an infinite set of patterns.

Allow/Deny is a beat around the bush. If you don’t want a user to update the location.lat field, but want them to update the location.lng field, and the name.first field but not the name.last field and definitely not the location.lng field is the value isn’t between [-180, and 180], and you only want them to update the posts field if the post in question satisfies a certain structure and has no words in the array [shit, damn, ...], and you definitely cannot have them messing around with the password field unless it has at least 10 characters, 3 uppercase, four special characters, and no spaces… eh…

JUST WRITE METHODS!!!

[raskal]

Suppose Meteor.methods were deprecated by an act of god , will it be possible just to use Meteor.isClient and Meteor.isServer and allow/deny to achieve the same result? I think so… simplistically, I think just making every js function defined in the common area a Meteor.method may do it. Thanks!

[copleykj]

I really have to disagree with the sentiment that somehow allow/deny is inferior to meteor methods. Obviously this will all become moot when Apollo is finally polished and migrated to, but for the time being allow/deny rules can be easily used in conjunction with SimpleSchema to create a very secure application in about half the time it would take you to implement the same mess using a method call. I proved this quite well with my submission to the Discover Meteor Allow/Deny Security Challenge and I currently use this technique for all of the packages in the Socialize set. Despite this fact the same nonsense is repeated time and time again until it becomes gospel.

[ramez]

We use allow / deny quite a bit. Like @copleykj mentioned, it is a secure and easy way to restrict write access.

At its infancy, Meteor was labelled insecure (I wasn’t around, so can’t comment). A big part of proper security is making it easy for developers to harden their code / server / DB. Asking us to start writing methods will surely result in some (or many) insecure apps.

Again, when dealing with security, it has to be SUPER easy for an idiot to harden their code. The moment you are labelled insecure you are toast. It’s a human thing, not just code.

[sashko]

Again, when dealing with security, it has to be SUPER easy for an idiot to harden their code. The moment you are labelled insecure you are toast. It’s a human thing, not just code.

Given two arbitrary code bases that are currently not secure, one using allow/deny and the other using methods, I’d much rather be given the job of securing the methods one. Here would be my workflow:

1. List all of the methods
2. Go through them one by one and enumerate the possible inputs, and the desired effects in those cases
3. Write tests for all of them to check various kinds of inputs, and use argument validation to disallow any other kind of input
4. Done

I can’t think of such a workflow for client-side updates and allow/deny. Is there one?

[ramez]

@sashko,

Maybe I am missing something.
If client-side updates went through a single pipe (allow/deny) your workflow would simply be:

1. Check your allow/deny code

Sounds too easy? Look forward to your reply.