Skip to content

Commit 0cef4e6

Browse files
authored
Add model policy example to README
1 parent bf26e5a commit 0cef4e6

File tree

1 file changed

+5
-0
lines changed

1 file changed

+5
-0
lines changed

README.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -23,6 +23,7 @@
2323
* [Using Blade directives](#using-blade-directives)
2424
* [Defining a Super-Admin](#defining-a-super-admin)
2525
* [Best Practices -- roles vs permissions](#best-practices----roles-vs-permissions)
26+
* [Best Practices -- Using Policies](#best-practices----using-policies)
2627
* [Using multiple guards](#using-multiple-guards)
2728
* [Using a middleware](#using-a-middleware)
2829
* [Using artisan commands](#using-artisan-commands)
@@ -641,6 +642,10 @@ It is generally best to code your app around `permissions` only. That way you ca
641642

642643
Roles can still be used to group permissions for easy assignment, and you can still use the role-based helper methods if truly necessary. But most app-related logic can usually be best controlled using the `can` methods, which allows Laravel's Gate layer to do all the heavy lifting.
643644

645+
## Best Practices -- Using Policies
646+
647+
The best way to incorporate access control for access to app features is with Model Policies. This way your application logic can be combined with your permission rules, keeping your implementation simpler. You can find an example of implementing a model policy with this Laravel Permissions package in this demo app: https://github.com/drbyte/spatie-permissions-demo/blob/master/app/Policies/PostPolicy.php
648+
644649

645650
## Using multiple guards
646651

0 commit comments

Comments
 (0)