You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 18, 2021. It is now read-only.
I would imagine you could have a subclass of model controller that only deals with objects that have a userId property, and then in any get, put, or delete request it makes sure the authorization for the request matches the userId otherwise returning a 403. For post requests it could fill in the userId on the valueObject.
The text was updated successfully, but these errors were encountered:
Agreed (not on the subclass part, but the need for this), I'm currently writing this code at the top of a lot of methods. To pull this off, the ModelController would effectively fetch the object in question prior to even entering the request handler methods. In a simple CRUD service, the GET {id} would basically be done. I think this would be configurable on the controller (just a flag set in the initializer) that defaulted to fetching the object. I think there would be times you'd want to avoid that behavior, but the more likely (Default) behavior should be fetch the object. Perhaps as a similar item, it'd be nice to optionally fetch more of the resource owner object during authentication. It'd be even nicer to do this as an annotation to the controller..
I would imagine you could have a subclass of model controller that only deals with objects that have a userId property, and then in any get, put, or delete request it makes sure the authorization for the request matches the userId otherwise returning a 403. For post requests it could fill in the userId on the valueObject.
The text was updated successfully, but these errors were encountered: