Per the subject...
Laravel uses five method calls in the policy classes to describe permissions: index, create, view, update, delete. These mean the same thing as your five in this package. I'd rather not separate policy settings because of a concern that policy changes in one space won't be replicated to the other.
Any thoughts or suggestions?
The Authorizer class is the way that you handle authorization of a JSON API request. I need to add an example to the demo app.
In essence there's an AbstractAuthorizer that can be extended and the authorizer is then injected into your Request class for a resource type (you'll see it's the first argument of the parent constructor).
Our approach is to hand off the Laravel policies via Gate within the Authorizer.
This might make more sense if I add it to the demo app. I'll try to do that but I have pressing work deadlines at the moment so not sure I'm going to be able to do it this week...
Sounds good, I'll give it a shot!
I'm reopening this as a reminder to add it to the demo.
Authorization all updated, documented and added to the demo app. See:
https://github.com/cloudcreativity/laravel-json-api/blob/master/docs/basics/security.md
Released as v1.0.0-alpha.2
Most helpful comment
Authorization all updated, documented and added to the demo app. See:
https://github.com/cloudcreativity/laravel-json-api/blob/master/docs/basics/security.md
Released as
v1.0.0-alpha.2