These are chat archives for Automattic/mongoose
findOnegoing for it. It also fits directly into the mongoose pattern of middleware either returning the doc or an error, plus the bonus that a lack of permissions being an error just feels right :)
BTW, for context, the module I'm working on is mongoose-authz. The readme is decent, but pretty out of date right now, but you'll get the gist.
It handles lack of permissions on write requests as an error. For read requests (find & findOne), it typically just tries to hide what you can't see. The permissions are down to the individual field level. So if a request is made trying to get a the
last_name fields, but the user is only authorized to see the
first_name field, the library will strip out the
last_name field and still return the info that the user can see. That let's an application consuming the data still work with what the user can do, and not have to check to see what fields can be accessed before doing the query.
find requests, the module will strip out entire objects from the result set if the user can't see them. That also feels right. For instance, if you ask for a list of all of someone's photos, but you can only see half of them, the request is still valid, and the correct half of the photos you can see are returned. This is easy for the module to accomplish since it can mutate the array and splice results out of that.
findOne, the result is just the single object, so it's not possible to return null. I think the answer for how this should behave is the same question about how mongoose should behave natively. Mongoose decided that
findOneshould return null when something is not found, and thus it seems like this library should do the same so the sematics of all the methods are the same.
That said, @lineus , I'm trying to wrap my models with
express-restify-mongoose. So I actually think an error would work in my particular case (since findOne is only used for id's), but I'm not sure it's the right, general solution