Permissions expansion

[deontologician]

Right now the permissions document is a good outline, but it should probably mention some practical things like

• query template rules are faster than javascript validator functions. Try to use them wherever possible
• query template rules can be combined with js validators, do this to have a "first pass" to rule out classes of validators so they don't have to run on every incoming query.

[chipotle]

Are there any other bits here you know of that could be thrown in here? Adding those two to the existing document should be pretty quick, but this is a good time to expand the bullet list if other things have come up in practice.

[mglukhovsky]

@segphault, since you've done a lot of work with permissions recently -- what else would you like to see documented?

[danielmewes]

This comes to mind: https://github.com/rethinkdb/horizon-docs/issues/71 Just pinged @Tryneus for some details on the index names...

[segphault]

In a replace operation, there's no way to check that the ID of the document hasn't changed, because Horizon uses the ID in the provided object to fetch the document used as oldValue in the validator check. While the behavior here is totally understandable, it did lead to some slightly counterintuitive results.

In my bookmarks app, with my initial naive set of permissions, it was possible for users to take advantage of the replace operation to overwrite bookmarks that belong to other users. I had to add a validator with an oldVal.user === newVal.user check in order to prevent it.