You don't need deny rules of insecure is removed
abhiaiyer91 opened this issue · 11 comments
Automatically clients won't be able to call db methods
@abhiaiyer91 I've reopened this because of sashko's comments here: https://forums.meteor.com/t/do-you-need-deny-methods-if-you-have-removed-insecure/19297. He's adamant you still need deny methods - Any thoughts?
(PS: Wasn't doubting you originally, I was planning to submit a PR to the Guide to clear up the ambiguity on this but then couldn't make sense of what it said, it seemed contradictory)
You're right with your comment:
Ah OK, maybe I've clicked, so calling allow elsewhere in the code would turn permissions back on. But if you have said deny then allow has no effect?
Quote from Meteor Docs:
When a client tries to write to a collection, the Meteor server first checks the collection's deny rules. If none of them return true then it checks the collection's allow rules. Meteor allows the write only if no deny rules return true and at least one allow rule returns true.
Writing deny rules for all collections prevents developers from accidentally using an allow rule elsewhere.
Thank you :) But is that rule checking client-side or server-side? Didn't removing insecure stop the client, and isn't the server always trusted (so allow/deny has no affect on the server)
The checking is server side, the server checks that the client is permitted. The insecure package basically adds an all encompassing allow rule for each collection.
- Client fires - Collection.insert({aweosmeObject})
- Server receives the request to insert
- Server checks the Deny and Allow rules for that collection and makes a decision based on above logic.
- If insecure is present, there are default Allow rules for the collection. If insecure is removed then the developers can still write their own Allow rules.
But if there's no insecure then doesn't the server only accept methods at step 2, and methods are allowed to write to the database no matter what allow/deny rules are set?
Or does allow/deny apply to methods too? If so, how did my methods work when I used to have this code: https://github.com/tomRedox/simpleCRM/blob/1a56df81476f890ca27f9734c916cd778a172a52/imports/api/customers/customer-company.js
My point is really, it seems like allow/deny only applies to attempts to write directly to the DB without the use of methods, but we removed the ability to not use methods when we removed insecure, so why do we then need allow/deny.
Sorry, this is probably just me having a total mental block!
Allow-Deny isn't a feature of the insecure module, its built into Meteor.
Insecure just adds some prebuilt allow rules essentially.
With insecure removed, we can still write an allow rule and clients can call collection.insert.
http://docs.meteor.com/#/full/allow
If you never set up any allow rules on a collection then all client writes to the collection will be denied, and it will only be possible to write to the collection from server-side code. In this case you will have to create a method for each possible write that clients are allowed to do. You'll then call these methods with Meteor.call rather than having the clients call insert, update, and remove directly on the collection.
Meteor also has a special "insecure mode" for quickly prototyping new applications. In insecure mode, if you haven't set up any allow or deny rules on a collection, then all users have full write access to the collection. This is the only effect of insecure mode.
OK, so my error here is that insecure is not related to methods, that's my fundamental misunderstanding?
Edit: So I should add those deny rules back in then.
Yes, Insecure simply adds some pre-fabbed allow rules. We don't necessarily need to have our own Deny rules - as the server will block anything without an allow rule. But by explicitly setting up Deny rules all on collections if prevents lazy developers from creating and using a dangerous allow rule.
I finally understand :) Thank you!
No worries - I'd suggest we put in Deny rules though. Better safe than sorry. =D
We had them, that's where this all started :) I'm just committing them back in now.