The easiest and most intuitive way to add access management to your Filament Admin:
- 🔥 Resources
- 🔥 Pages
- 🔥 Widgets
- 🔥 Custom Permissions
Note
For Filament 2.x use 2.x branch
Important
Prior to v3.1.0
Shield supported spatie/laravel-permission:^5.0
and now it supports version ^6.0
. Which has some breaking changes around migrations. If you are upgrading from a version prior to v3.1.0
please make sure to remove the old migration file and republish the new one.
- Install the package via composer:
composer require bezhansalleh/filament-shield
- Add the
Spatie\Permission\Traits\HasRoles
trait to your User model(s):
use Illuminate\Foundation\Auth\User as Authenticatable;
use Spatie\Permission\Traits\HasRoles;
class User extends Authenticatable
{
use HasRoles;
// ...
}
- Publish the
config
file then setup your configuration:
php artisan vendor:publish --tag=filament-shield-config
- Register the plugin for the Filament Panels you want
public function panel(Panel $panel): Panel
{
return $panel
->plugins([
\BezhanSalleh\FilamentShield\FilamentShieldPlugin::make()
]);
}
- Now run the following command to install shield:
php artisan shield:install
Follow the prompts and enjoy!
If you want to enable Shield
for more than one panel then you need to register the plugin for each panel as mentioned above.
Shield comes with the HasPanelShield
trait which provides an easy way to integrate Shield's conventions with the Filament's panel access system.
The HasPanelShield
trait provides an implementation for the canAccessPanel
method, determining access based on whether the user possesses the super_admin
role or the panel_user
role. It also assigns the panel_user
role to the user upon creation and removes it upon deletion. Ofcourse the role names can be changed from the plugin's configuration file.
use BezhanSalleh\FilamentShield\Traits\HasPanelShield;
use Filament\Models\Contracts\FilamentUser;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Spatie\Permission\Traits\HasRoles;
class User extends Authenticatable implements FilamentUser
{
use HasRoles;
use HasPanelShield;
// ...
}
Generally there are two scenarios that shield handles permissions for your Filament
resources.
Out of the box Shield
handles the predefined permissions for Filament
resources. So if that's all that you need you are all set.
If you need to add a single permission (for instance lock
) and have it available for all your resources just append it to the following config
key:
permission_prefixes' => [
'resource' => [
'view',
'view_any',
'create',
'update',
'restore',
'restore_any',
'replicate',
'reorder',
'delete',
'delete_any',
'force_delete',
'force_delete_any',
'lock'
],
...
],
💡 Now you are thinking what if I need a permission to be only available for just one resource?
No worries, that's where Custom Permissions come to play.
To define custom permissions per Resource
your Resource
must implement the HasShieldPermissions
contract.
This contract has a getPermissionPrefixes()
method which returns an array of permission prefixes for your Resource
.
Consider you have a PostResource
and you want a couple of the predefined permissions plus a new permission called publish_posts
to be only available for PostResource
only.
<?php
namespace BezhanSalleh\FilamentShield\Resources;
use BezhanSalleh\FilamentShield\Contracts\HasShieldPermissions;
...
class PostResource extends Resource implements HasShieldPermissions
{
...
public static function getPermissionPrefixes(): array
{
return [
'view',
'view_any',
'create',
'update',
'delete',
'delete_any',
'publish'
];
}
...
}
In the above example the getPermissionPrefixes()
method returns the permission prefixes Shield
needs to generate the permissions.
✅ Now to enforce publish_post
permission headover to your PostPolicy
and add a publish()
method:
/**
* Determine whether the user can publish posts.
*
* @param \App\Models\User $admin
* @return \Illuminate\Auth\Access\Response|bool
*/
public function publish(User $user)
{
return $user->can('publish_post');
}
Shield
's translations and append the prefix inside resource_permission_prefixes_labels
as key and it's translation as value for the languages you need.
//lang/en/filament-shield.php
'resource_permission_prefixes_labels' => [
'publish' => 'Publish'
],
//lang/es/filament-shield.php
'resource_permission_prefixes_labels' => [
'publish' => 'Publicar'
],
By default the permission identifier is generated as follow:
Str::of($resource)
->afterLast('Resources\\')
->before('Resource')
->replace('\\', '')
->snake()
->replace('_', '::');
So for instance if you have a resource like App\Filament\Resources\Shop\CategoryResource
then the permission identifier would be shop::category
and then it would be prefixed with your defined prefixes or what comes default with shield.
If you wish to change the default behaviour, then you can call the static configurePermissionIdentifierUsing()
method inside a service provider's boot()
method, to which you pass a Closure to modify the logic. The Closure receives the fully qualified class name of the resource as $resource
which gives you the ability to access any property or method defined within the resource.
For example, if you wish to use the model name as the permission identifier, you can do it like so:
use BezhanSalleh\FilamentShield\Facades\FilamentShield;
FilamentShield::configurePermissionIdentifierUsing(
fn($resource) => str($resource::getModel())
->afterLast('\\')
->lower()
->toString()
);
Warning Keep in mind that ensuring the uniqueness of the permission identifier is now up to you.
By default the english translation renders Roles and Permissions under 'Filament Shield' if you wish to change this, first publish the translations files and change the relative locale to the group of your choosing for example:
'nav.group' => 'Filament Shield',
to
'nav.group' => 'User Management',
apply this to each language you have groups in.
If you have generated permissions for Pages
you can toggle the page's navigation from sidebar and restrict access to the page. You can set this up manually but this package comes with a HasPageShield
trait to speed up this process. All you have to do is use the trait in you pages:
<?php
namespace App\Filament\Pages;
use ...;
use BezhanSalleh\FilamentShield\Traits\HasPageShield;
class MyPage extends Page
{
use HasPageShield;
...
}
📕 HasPageShield
uses the booted
method to check the user's permissions and makes sure to execute the booted
page method in the parent page if exists.
However if you need to perform some methods before and after the booted method you can declare the next hooks methods in your filament page.
<?php
namespace App\Filament\Pages;
use ...;
use BezhanSalleh\FilamentShield\Traits\HasPageShield;
class MyPage extends Page
{
use HasPageShield;
...
protected function beforeBooted : void() {
...
}
protected function afterBooted : void() {
...
}
/**
* Hook to perform an action before redirect if the user
* doesn't have access to the page.
* */
protected function beforeShieldRedirects : void() {
...
}
}
HasPageShield
uses the config('filament.path')
value by default to perform the shield redirection. If you need to overwrite the rediretion path, just add the next method to your page:
<?php
namespace App\Filament\Pages;
use ...;
use BezhanSalleh\FilamentShield\Traits\HasPageShield;
class MyPage extends Page
{
use HasPageShield;
...
protected function getShieldRedirectPath(): string {
return '/'; // redirect to the root index...
}
}
if you have generated permissions for Widgets
you can toggle their state based on whether a user have permission or not. You can set this up manually but this package comes with a HasWidgetShield
trait to speed up this process. All you have to do is use the trait in you widgets:
<?php
namespace App\Filament\Widgets;
use ...;
use BezhanSalleh\FilamentShield\Traits\HasWidgetShield;
class IncomeWidget extends LineChartWidget
{
use HasWidgetShield;
...
}
To ensure RoleResource
access via RolePolicy
you would need to add the following to your AuthServiceProvider
:
//AuthServiceProvider.php
...
protected $policies = [
'Spatie\Permission\Models\Role' => 'App\Policies\RolePolicy',
];
...
To ensure RoleResource
access via RolePolicy
you would need to add the following to your AppServiceProvider
:
//AppServiceProvider.php
use Illuminate\Support\Facades\Gate;
...
public function boot(): void
{
...
Gate::policy(\Spatie\Permission\Models\Role::class, \App\Policies\RolePolicy::class);
}
...
whatever your version of Laravel, you can skip it if you have enabled it from the config
:
// config/filament-shield.php
...
'register_role_policy' => [
'enabled' => true,
],
...
If your policies are not in the default Policies
directory in the app_path()
you can change the directory name in the config file:
...
'generator' => [
'option' => 'policies_and_permissions',
'policy_directory' => 'Policies',
],
...
Shield also generates policies and permissions for third-party plugins and Models
with custom folder structure and to enforce the generated policies you will need to register them.
//AuthServiceProvider.php
...
class AuthServiceProvider extends ServiceProvider
{
...
protected $policies = [
...,
'App\Models\Blog\Author' => 'App\Policies\Blog\AuthorPolicy',
'Ramnzys\FilamentEmailLog\Models\Email' => 'App\Policies\EmailPolicy'
];
//AppServiceProvider.php
use Illuminate\Support\Facades\Gate;
...
class AppServiceProvider extends ServiceProvider
{
...
public function boot(): void
{
...
Gate::policy(\App\Models\Blog\Author::class, \App\Policies\Blog\AuthorPolicy::class);
Gate::policy(\Ramnzys\FilamentEmailLog\Models\Email::class, \App\Policies\EmailPolicy::class);
}
Shield does not come with a way to assign roles to your users out of the box, however you can easily assign roles to your users using Filament Forms
's Select
or CheckboxList
component. Inside your users Resource
's form add one of these components and configure them as you need:
// Using Select Component
Forms\Components\Select::make('roles')
->relationship('roles', 'name')
->multiple()
->preload()
->searchable()
// Using CheckboxList Component
Forms\Components\CheckboxList::make('roles')
->relationship('roles', 'name')
->searchable()
You can find out more about these components in the Filament Docs
You can easily customize the Grid
, Section
and CheckboxList
's columns()
and columnSpan()
without publishing the resource.
use BezhanSalleh\FilamentShield\FilamentShieldPlugin;
public function panel(Panel $panel): Panel
{
return $panel
...
...
->plugins([
FilamentShieldPlugin::make()
->gridColumns([
'default' => 1,
'sm' => 2,
'lg' => 3
])
->sectionColumnSpan(1)
->checkboxListColumns([
'default' => 1,
'sm' => 2,
'lg' => 4,
])
->resourceCheckboxListColumns([
'default' => 1,
'sm' => 2,
]),
]);
}
Publish the translations using:
php artisan vendor:publish --tag="filament-shield-translations"
- Show useful info about Filament Shield.
Setup Core Package requirements and Install Shield. Accepts the following flags:
--fresh
re-run the migrations--only
Only setups shield without generating permissions and creating super-admin
Generate Permissions and/or Policies for Filament entities. Accepts the following flags:
--all
Generate permissions/policies for all entities--option[=OPTION]
Override the config generator option(policies_and_permissions
,policies
,permissions
)--resource[=RESOURCE]
One or many resources separated by comma (,)--page[=PAGE]
One or many pages separated by comma (,)--widget[=WIDGET]
One or many widgets separated by comma (,)--exclude
Exclude the given entities during generation--ignore-config-exclude
Ignore configexclude
option during generation--ignore-existing-policies
Do not overwrite the existing policies.
Create a user with super_admin role.
- Accepts an
--user=
argument that will use the provided ID to find the user to be made super admin.
- Publish the Shield
RoleResource
and customize it however you like
- Deploy easily by setting up your roles and permissions or add your custom seeds
composer test
Please see CHANGELOG for more information on what has changed recently.
Please see CONTRIBUTING for details.
Please review our security policy on how to report security vulnerabilities.
The MIT License (MIT). Please see License File for more information.