I want this change so I can add logic as a consumer of angular-bridge to make sure the user hitting the endpoint is authorized to hit the endpoint. So for me, this change is for authentication purposes. But this simple change could have other use cases as well... Notes: - This is backward compatible (nobody will need to change anything to upgrade to this version) - I used the name requestPrehandler because I thought that was the most descriptive of what it does. Even though the main value I can see is for security purposes, there are other use cases so I didn't want to use the name "authorize" or something like that. - I toyed around with the idea of having the option be resource for resource... Maybe that would be the better way to go about doing this (maybe I'll submit another pull request for that method as well). I opted out of that for simplicity's sake. However, it may be easier for consumers of this api to add a requestPrehandler on a per resource basis... Thoughts? I'm happy to accept changes to style and/or method.
– uses eval(), could use improvement – updated readme
(they need to be defined in the schema.methods definition as docSchema.methods.get, docSchema.methods.delete, etc...)
…ving collection – if the query comes in as a string or an object, it will handle it appropriately either way (uses eval(), be careful)
(sorry if this offends anyone)