Proposal: updateHandler to use findById() + findOneAndUpdate() about rest-hapi HOT 9 CLOSED

I see, it sounds like you're looking for a method of document specific authorization, which is definitely a feature I would like to add in the near future. Ideally it would perform similar to route specific authorization (most likely utilizing hapi scopes somehow) but on a document level.

I still believe the best way to accomplish the update queries would be through a new PUT /model endpoint. That way rather than changing and possibly breaking the update: pre and update: post methods there could be a new upsert: pre and upsert: post option that would correctly handle the query. Then you could simply pass { _id: _id } as the query and add the account property in the upsert: pre middleware. Would that work for you?

from rest-hapi.

Interesting idea, I'll check out your POC. Could you give an example use case for this? My initial thought is that the findById is redundant/unnecessary if the query filter is used. It's not clear to me how filtering by both _id and query is useful.

Maybe the simplest solution is to create another endpoint PUT /model that accepts a query filter rather than an _id parameter to filter by. Seems like that would present a clear separation between the functionality of PUT /model/{_id} and PUT /model without having to worry about backwards compatibility.

from rest-hapi.

Another thought is PUT /model could accept an $upsert query property that would allow insertions if no document matches are found.

from rest-hapi.

My use case is simply to prevent users from accessing content belonging to other users.

GET /model/{_id}, instead of doing a query for { _id: _id }, will do a query for { _id: _id, account: request.auth.credentials.account }. If the document with that _id has that account, it will be returned; otherwise the endpoint returns a 404.

In the same way, PUT /model/{_id}, instead of doing a query for { _id: _id }, will do a query for { _id: _id, account: request.auth.credentials.account }. If the document with that _id has that account, it will be updated; otherwise the endpoint returns a 404.

from rest-hapi.

Yes, document-specific authorization is what I'm going for.

If the document I'm looking for isn't found (either because it doesn't exist, or because it has different value for account), I don't want to do an upsert; I just want to return a 404. Would that work with the proposed PUT /model endpoint?

The nice thing about having this work with the PUT /model/{_id} endpoint is that it's transparent to the client.

What if there were a flag under routeOptions to get my proposed behavior? Or a different middleware method that explicitly returns the payload and the query?

from rest-hapi.

I should mention that I'll also be needing document-specific authorization for the delete endpoint.

from rest-hapi.

If the document I'm looking for isn't found (either because it doesn't exist, or because it has different value for account), I don't want to do an upsert; I just want to return a 404. Would that work with the proposed PUT /model endpoint?

Yes, given that a boolean $upsert query option could be passed in. If $upsert is set to false, then a 404 would be returned.

The nice thing about having this work with the PUT /model/{_id} endpoint is that it's transparent to the client.

Hmm, I guess I'm not following. How would PUT /model/{_id} be more transparent than PUT /model?

What if there were a flag under routeOptions to get my proposed behavior? Or a different middleware method that explicitly returns the payload and the query?

I suppose this could be done, I could imaging PUT /model/{_id} supporting both an upsert:pre/post and update:pre/post, however this would probably be more complicated than adding another endpoint with the functionality. I also think two endpoints gives a better separation of concerns. There might be times when you want to update a document based on a query that doesn't include the _id. PUT /model/{_id} forces you to include an _id, so that would never be an option.

I should mention that I'll also be needing document-specific authorization for the delete endpoint.

That would be included in #50, however I'm not sure the best/possible way to accomplish this currently.

from rest-hapi.

By "transparent", I mean that, as far as the implement of the client is concerned, there is no difference between the API having document-specific authorization and not having it. If the client has to hit another endpoint, then the difference is visible to the client.

Having a separate endpoint to allow updating a document (or documents) based on a query without _id does sound useful. But even with such an endpoint, I think it would still be useful to have document specific authorization on the existing _id endpoint.

Anyway, thank you for considering this! For now I'll wait and see what develops in #50.

from rest-hapi.

@tamias just pushed an update that includes document-specific authorization.

Also, I provided an example of how to accomplish a task similar to your use-case mentioned in this issue. It takes advantage of the new policies feature. Please see the docs here.

from rest-hapi.