'permit' is not defined in client code about meteor-security

[aldeed]

Is that common code? This package API is available only on the server, and in general it's not a good idea to have your rules defined in code that is sent to the client since your rule might be wrong and anyone would be able to see that and exploit it more easily.

[fuzzybabybunny]

Oh, I see. This obviously makes a lot of sense, but the reason I put this code into common code is because the Discover Meteor book actually has all of their Deny and Allow code in the lib/collections folder, so common code (for the record, I thought this was strange, but chalked it up to them wanting to use latency compensation). I simply followed the same pattern. Perhaps add in the ReadMe that this security package should be defined on the server?

[aldeed]

I agree it's confusing, mostly because Meteor documents allow/deny as server-only but yet defines them in common code. For now we'll keep this pkg server-only, but if the Meteor docs ever change to indicate they officially support calling allow/deny on the client, then we can probably do the same. Just because I'm opinionated does not mean this pkg has to be.

In the meantime, I clarified the readme.

cc: @estark37 and @SachaG

[SachaG]

I also find it confusing. In fact I think I had just assumed allow and deny ran on the client too…