bouncer
v1.0.2
Bouncer は、Eloquent モデルを使用してアプリの役割と機能を管理するための、フレームワークに依存しないエレガントなアプローチです。
bouncer:cleanBouncer は、Eloquent モデルを使用してアプリの役割と機能を管理するための、フレームワークに依存しないエレガントなアプローチです。表現力豊かで流暢な構文により、できる限り邪魔になりません。使いたいときに使い、使いたくないときは無視してください。
Bouncer の機能を簡単に一目で確認できるリストについては、チートシートをご覧ください。
バウンサーは、独自のアプリにハードコーディングされた他の機能とうまく連携します。コードは常に優先されます。コードでアクションが許可されている場合、Bouncer は干渉しません。
インストールしたら、ゲートで何を許可したいかを警備員に伝えるだけです。
// Give a user the ability to create posts
Bouncer:: allow ( $ user )-> to ( ' create ' , Post::class);
// Alternatively, do it through a role
Bouncer:: allow ( ' admin ' )-> to ( ' create ' , Post::class);
Bouncer:: assign ( ' admin ' )-> to ( $ user );
// You can also grant an ability only to a specific model
Bouncer:: allow ( $ user )-> to ( ' edit ' , $ post );Laravelのゲートで能力を確認すると、自動的にBouncerが相談されます。 Bouncer は、現在のユーザーに (直接またはロールを通じて) 付与された機能を認識すると、チェックを許可します。
注: Bouncer v1.0.2 には、PHP 8.2 以降および Laravel/Eloquent 11 以降が必要です。
Laravel v6 ～ v10 を使用している場合は、Bouncer v1.0.1 を使用してください。 Laravel v5.5 ～ v5.8 を使用している場合は、Bouncer RC6 を使用してください。
Composer を使用して Bouncer をインストールします。
composer require silber/bouncer
バウンサーの特性をユーザー モデルに追加します。
use Silber Bouncer Database HasRolesAndAbilities ;
class User extends Model
{
use HasRolesAndAbilities;
}次に、Bouncer の移行を実行します。まず、次のコマンドを実行して、アプリのmigrationsディレクトリに移行を公開します。
php artisan vendor:publish --tag="bouncer.migrations"
最後に、移行を実行します。
php artisan migrate
コードでBouncerファサードを使用するときは、ファイルの先頭にある名前空間インポートに必ず次の行を追加してください。
use Bouncer ;Laravel ファサードの詳細については、Laravel のドキュメントを参照してください。
Composer を使用して Bouncer をインストールします。
composer require silber/bouncer
Eloquent Capsule コンポーネントを使用してデータベースをセットアップします。
use Illuminate Database Capsule Manager as Capsule ;
$ capsule = new Capsule ;
$ capsule -> addConnection ([ /* connection config */ ]);
$ capsule -> setAsGlobal ();詳細については、Eloquent Capsule のドキュメントを参照してください。
次のいずれかの方法で移行を実行します。
vagabond などのツールを使用して、Laravel アプリの外部で Laravel 移行を実行します。必要な移行は移行スタブ ファイルにあります。
あるいは、生の SQL をデータベース内で直接実行することもできます。
バウンサーの特性をユーザー モデルに追加します。
use Illuminate Database Eloquent Model ;
use Silber Bouncer Database HasRolesAndAbilities ;
class User extends Model
{
use HasRolesAndAbilities;
}バウンサーのインスタンスを作成します。
use Silber Bouncer Bouncer ;
$ bouncer = Bouncer:: create ();
// If you are in a request with a current user
// that you'd wish to check permissions for,
// pass that user to the "create" method:
$ bouncer = Bouncer:: create ( $ user );アプリで依存関係の注入を使用している場合は、 Bouncerインスタンスをコンテナーにシングルトンとして登録できます。
use Silber Bouncer Bouncer ;
use Illuminate Container Container ;
Container:: getInstance ()-> singleton (Bouncer::class, function () {
return Bouncer:: create ();
}); Bouncer を必要とするクラスにBouncerを挿入できるようになりました。
createメソッドは、適切なデフォルトを使用してBouncerインスタンスを作成します。完全にカスタマイズするには、 makeメソッドを使用してファクトリ インスタンスを取得します。ファクトリでcreate()呼び出して、 Bouncerインスタンスを作成します。
use Silber Bouncer Bouncer ;
$ bouncer = Bouncer:: make ()
-> withCache ( $ customCacheInstance )
-> create (); Factoryクラスをチェックして、利用可能なすべてのカスタマイズを確認してください。
アプリ全体でユーザー モデルとして使用されるモデルを設定します。
$ bouncer -> useUserModel (User::class);追加の構成については、以下の「構成」セクションを参照してください。
デフォルトでは、Bouncer のクエリは現在のリクエストに対してキャッシュされます。パフォーマンスを向上させるために、クロスリクエスト キャッシュを有効にすることもできます。
ユーザーに役割と能力を追加するのは非常に簡単です。事前に役割や能力を作成する必要はありません。ロール/アビリティの名前を渡すだけで、存在しない場合は Bouncer が作成します。
注:以下の例はすべて
Bouncerファサードを使用しています。ファサードを使用しない場合は、代わりにSilberBouncerBouncerのインスタンスをクラスに挿入できます。
adminというロールを作成し、サイトからban-users機能を与えましょう。
Bouncer:: allow ( ' admin ' )-> to ( ' ban-users ' );それでおしまい。バウンサーは舞台裏でRoleモデルとAbilityモデルの両方を作成します。
人間が判読できるタイトルなどの追加の属性をロール/アビリティに追加する場合は、 Bouncerクラスのroleおよびabilityメソッドを使用して手動で属性を作成できます。
$ admin = Bouncer:: role ()-> firstOrCreate ([
' name ' => ' admin ' ,
' title ' => ' Administrator ' ,
]);
$ ban = Bouncer:: ability ()-> firstOrCreate ([
' name ' => ' ban-users ' ,
' title ' => ' Ban users ' ,
]);
Bouncer:: allow ( $ admin )-> to ( $ ban );ユーザーにadminロールを付与するには、指定されたユーザーに管理者ロールを割り当てる必要があることをバウンサーに伝えるだけです。
Bouncer:: assign ( ' admin ' )-> to ( $ user );あるいは、ユーザーに対してassignメソッドを直接呼び出すこともできます。
$ user -> assign ( ' admin ' );場合によっては、ロールを使用せずにユーザーに直接能力を付与したい場合があります。
Bouncer:: allow ( $ user )-> to ( ' ban-users ' );ここでも、ユーザーから直接同じことを実行できます。
$ user -> allow ( ' ban-users ' );場合によっては、機能を特定のモデル タイプに制限したい場合があります。モデル名を 2 番目の引数として渡すだけです。
Bouncer:: allow ( $ user )-> to ( ' edit ' , Post::class);機能を特定のモデル インスタンスに制限したい場合は、代わりに実際のモデルを渡します。
Bouncer:: allow ( $ user )-> to ( ' edit ' , $ post );toOwnメソッドを使用して、ユーザーが独自のモデルを管理できるようにします。
Bouncer:: allow ( $ user )-> toOwn (Post::class);これで、ユーザーが特定の投稿に対してアクションを実行できるかどうかをゲートでチェックするときに、投稿のuser_idログインしているユーザーのidと比較されます (これはカスタマイズ可能)。それらが一致すると、ゲートはアクションを許可します。
上記により、ユーザーの「所有」モデルに対するすべての機能が付与されます。続いてtoメソッドを呼び出すことで、機能を制限できます。
Bouncer:: allow ( $ user )-> toOwn (Post::class)-> to ( ' view ' );
// Or pass it an array of abilities:
Bouncer:: allow ( $ user )-> toOwn (Post::class)-> to ([ ' view ' , ' update ' ]);ユーザーがアプリケーション内のすべてのタイプのモデルを所有できるようにすることもできます。
Bouncer:: allow ( $ user )-> toOwnEverything ();
// And to restrict ownership to a given ability
Bouncer:: allow ( $ user )-> toOwnEverything ()-> to ( ' view ' );用心棒は、ユーザーから以前に割り当てられた役割を撤回することもできます。
Bouncer:: retract ( ' admin ' )-> from ( $ user );または、ユーザーに対して直接実行します。
$ user -> retract ( ' admin ' );用心棒は、ユーザーに以前に付与された能力を削除することもできます。
Bouncer:: disallow ( $ user )-> to ( ' ban-users ' );またはユーザーに直接:
$ user -> disallow ( ' ban-users ' );注:ユーザーが
ban-usersできるロールを持っている場合、その権限は引き続き残ります。これを禁止するには、ロールから機能を削除するか、ユーザーからロールを撤回します。
役割を通じて能力が付与されている場合は、代わりに役割から能力を削除するように用心棒に指示します。
Bouncer:: disallow ( ' admin ' )-> to ( ' ban-users ' );特定のモデル タイプの機能を削除するには、その名前を 2 番目の引数として渡します。
Bouncer:: disallow ( $ user )-> to ( ' delete ' , Post::class);警告:ユーザーが特定の
$postインスタンスをdelete権限を持っている場合、上記のコードはその権限を削除しません。以下に示すように、実際の$post2 番目の引数として渡すことで、この機能を個別に削除する必要があります。
特定のモデル インスタンスの機能を削除するには、代わりに実際のモデルを渡します。
Bouncer:: disallow ( $ user )-> to ( ' delete ' , $ post );注:
disallowメソッドは、このユーザー/ロールに以前に付与されていた能力のみを削除します。より一般的な能力で許可されているもののサブセットを禁止したい場合は、forbidメソッドを使用します。
バウンサーでは、よりきめ細かい制御のために、特定の能力forbidこともできます。場合によっては、ユーザー/ロールに幅広いアクションをカバーする能力を付与し、それらのアクションの小さなサブセットを制限したい場合があります。
以下にいくつかの例を示します。
ユーザーに通常はすべてのドキュメントの表示を許可しますが、特定の高度に機密扱いのドキュメントについては表示を許可しないようにすることができます。
Bouncer:: allow ( $ user )-> to ( ' view ' , Document::class);
Bouncer:: forbid ( $ user )-> to ( ' view ' , $ classifiedDocument ); superadmin者に、ユーザーの追加/削除を含むアプリ内でのすべての操作を許可したい場合があります。そうすれば、ユーザーの管理以外のあらゆることを実行できるadmin役割を持つことができます。
Bouncer:: allow ( ' superadmin ' )-> everything ();
Bouncer:: allow ( ' admin ' )-> everything ();
Bouncer:: forbid ( ' admin ' )-> toManage (User::class);場合によっては、ユーザーを禁止して、すべての機能に対する許可を削除することもできます。しかし、実際に彼らの役割と能力をすべて削除すると、禁止が解除されたときに彼らの元の役割と能力が何であったかを把握する必要があることを意味します。
禁止された能力を使用するということは、既存の役割と能力をすべて保持できるものの、何も許可されないことを意味します。これは、すべてを禁止する特別なbannedロールを作成することで実現できます。
Bouncer:: forbid ( ' banned ' )-> everything ();次に、ユーザーを禁止する場合は常に、そのユーザーにbannedロールを割り当てます。
Bouncer:: assign ( ' banned ' )-> to ( $ user );禁止を解除するには、単にユーザーからロールを撤回します。
Bouncer:: retract ( ' banned ' )-> from ( $ user );ご覧のとおり、Bouncer の禁止された機能により、アプリ内の権限を細かく制御できます。
禁止された能力を削除するには、 unforbidメソッドを使用します。
Bouncer:: unforbid ( $ user )-> to ( ' view ' , $ classifiedDocument );注: これにより、以前に禁止されていた能力が削除されます。このユーザー/ロールに付与された別の通常の能力によってすでに許可されていない場合、その能力は自動的に許可されません。
注: 一般的に、ロールを直接確認する必要はありません。ロールに特定の能力を許可してから、代わりにそれらの能力を確認することをお勧めします。必要なものが非常に一般的な場合は、非常に幅広い能力を作成できます。たとえば、
access-dashboard機能は、adminまたはeditorの役割を直接確認するよりも常に優れています。まれにロールを確認したい場合は、その機能をここで利用できます。
バウンサーは、ユーザーが特定の役割を持っているかどうかを確認できます。
Bouncer:: is ( $ user )-> a ( ' moderator ' );チェックしているロールが母音で始まる場合は、 anメソッドを使用するとよいでしょう。
Bouncer:: is ( $ user )-> an ( ' admin ' );逆に、ユーザーが特定のロールを持っていないかどうかを確認することもできます。
Bouncer:: is ( $ user )-> notA ( ' moderator ' );
Bouncer:: is ( $ user )-> notAn ( ' admin ' );ユーザーが多くのロールのいずれかを持っているかどうかを確認できます。
Bouncer:: is ( $ user )-> a ( ' moderator ' , ' editor ' );ユーザーが指定されたロールをすべて持っているかどうかを確認することもできます。
Bouncer:: is ( $ user )-> all ( ' editor ' , ' moderator ' );ユーザーが指定されたロールを持っていないかどうかを確認することもできます。
Bouncer:: is ( $ user )-> notAn ( ' editor ' , ' moderator ' );これらのチェックは、ユーザーに対して直接実行することもできます。
$ user -> isAn ( ' admin ' );
$ user -> isA ( ' subscriber ' );
$ user -> isNotAn ( ' admin ' );
$ user -> isNotA ( ' subscriber ' );
$ user -> isAll ( ' editor ' , ' moderator ' );ユーザーに特定のロールがあるかどうかをクエリできます。
$ users = User:: whereIs ( ' admin ' )-> get ();複数のロールを渡して、指定されたロールのいずれかを持つユーザーをクエリすることもできます。
$ users = User:: whereIs ( ' superadmin ' , ' admin ' )-> get ();指定されたすべてのロールを持つユーザーをクエリするには、 whereIsAllメソッドを使用します。
$ users = User:: whereIsAll ( ' sales ' , ' marketing ' )-> get ();ユーザーのすべてのロールをユーザー モデルから直接取得できます。
$ roles = $ user -> getRoles ();ユーザーのすべての能力をユーザー モデルから直接取得できます。
$ abilities = $ user -> getAbilities ();これにより、ロールを通じてユーザーに付与されたすべての能力を含む、ユーザーの許可された能力のコレクションが返されます。
明示的に禁止されている能力のリストを取得することもできます。
$ forbiddenAbilities = $ user -> getForbiddenAbilities ();ユーザーの認可は、Laravel のGateまたはユーザーモデル ( $user->can($ability) ) で直接処理されます。
便宜上、 Bouncerクラスは次のパススルー メソッドを提供します。
Bouncer:: can ( $ ability );
Bouncer:: can ( $ ability , $ model );
Bouncer:: canAny ( $ abilities );
Bouncer:: canAny ( $ abilities , $ model );
Bouncer:: cannot ( $ ability );
Bouncer:: cannot ( $ ability , $ model );
Bouncer:: authorize ( $ ability );
Bouncer:: authorize ( $ ability , $ model );これらは、 Gateクラスの同等のメソッドを直接呼び出します。
Bouncer は独自のブレード ディレクティブを追加しません。 Bouncer は Laravel のゲートと直接連携するため、 @canディレクティブを使用して現在のユーザーの能力を確認するだけです。
@can ('update', $post)
< a href =" {{ route('post.update', $post) }} " > Edit Post </ a >
@endcanロールを直接確認することは一般に推奨されないため、Bouncer にはそのための個別のディレクティブが同梱されていません。それでもロールを確認したい場合は、一般的な@ifディレクティブを使用して確認できます。
@ if ( $ user -> isAn ( ' admin ' ))
//
@endifBouncer によって実行されたすべてのクエリは、現在のリクエストに対してキャッシュされます。クロスリクエスト キャッシュを有効にすると、キャッシュはさまざまなリクエストにわたって保持されます。
必要に応じていつでも、バウンサーのキャッシュを完全に更新できます。
Bouncer:: refresh ();注:すべてのユーザーのキャッシュを完全に更新するには、キャッシュ タグが使用可能な場合はそれを使用します。すべてのキャッシュ ドライバーがこれをサポートしているわけではありません。ドライバーがキャッシュタグをサポートしているかどうかを確認するには、Laravel のドキュメントを参照してください。ドライバーがキャッシュ タグをサポートしていない場合、システム内のユーザーの数によっては、
refreshの呼び出しが少し遅くなる可能性があります。
あるいは、特定のユーザーのみのキャッシュを更新することもできます。
Bouncer:: refreshFor ( $ user );注: マルチテナンシー スコープを使用する場合、現在のスコープのコンテキスト内のユーザーのキャッシュのみが更新されます。別のスコープ コンテキストで同じユーザーのキャッシュされたデータをクリアするには、そのスコープ内から呼び出す必要があります。
Bouncer はマルチテナント アプリを完全にサポートしているため、同じアプリ内のすべてのテナントに対する Bouncer の役割と機能をシームレスに統合できます。
開始するには、まずスコープ ミドルウェアをアプリに公開します。
php artisan vendor:publish --tag="bouncer.middleware"
ミドルウェアはapp/Http/Middleware/ScopeBouncer.phpに公開されます。このミドルウェアは、現在のリクエストにどのテナントを使用するかを Bouncer に指示する場所です。たとえば、すべてのユーザーがaccount_id属性を持っていると仮定すると、ミドルウェアは次のようになります。
public function handle ( $ request , Closure $ next )
{
$ tenantId = $ request -> user ()-> account_id ;
Bouncer:: scope ()-> to ( $ tenantId );
return $ next ( $ request );
}もちろん、サブドメインなどからテナント情報を取得するなど、アプリのニーズに合わせてこのミドルウェアを自由に変更できます。
ミドルウェアを配置したら、それを HTTP カーネルに登録してください。
protected $ middlewareGroups = [
' web ' => [
// Keep the existing middleware here, and add this:
App Http Middleware ScopeBouncer::class,
]
];Bouncer のすべてのクエリは、指定されたテナントにスコープされるようになります。
アプリの設定によっては、実際にはすべてのクエリのスコープを現在のテナントに限定する必要がない場合があります。たとえば、すべてのテナントで同じ役割/能力の固定セットを設定し、どのユーザーにどの役割が割り当てられるか、どの役割がどの能力を持つかを制御することのみをユーザーに許可することができます。これを実現するには、Bouncer のスコープに、モデル自体ではなく、Bouncer のモデル間の関係のみをスコープするように指示できます。
Bouncer:: scope ()-> to ( $ tenantId )-> onlyRelations ();さらに、アプリでは、特定の役割が持つ機能をユーザーが制御できない場合もあります。その場合、Bouncer のスコープにロールの能力をスコープから除外するよう指示し、これらの関係がすべてのテナントにわたってグローバルに維持されるようにします。
Bouncer:: scope ()-> to ( $ tenantId )-> onlyRelations ()-> dontScopeRoleAbilities ();ニーズが上で概説したものよりもさらに特殊な場合は、必要なカスタム ロジックを使用して独自のScopeを作成できます。
use Silber Bouncer Contracts Scope ;
class MyScope implements Scope
{
// Whatever custom logic your app needs
}次に、サービス プロバイダーでカスタム スコープを登録します。
Bouncer:: scope ( new MyScope ); Bouncer は、実行中のさまざまな時点でScopeインターフェイスのメソッドを呼び出します。特定のニーズに応じて自由に処理できます。
Bouncer には適切なデフォルトが同梱されているため、ほとんどの場合、設定を行う必要はありません。より詳細な制御を行うには、 Bouncerクラスのさまざまな構成メソッドを呼び出して、Bouncer をカスタマイズできます。
これらの構成オプションのうち 1 つまたは 2 つだけを使用する場合は、それらをメインのAppServiceProviderのbootメソッドに組み込むことができます。それらが大きくなり始めた場合は、 app/Providersディレクトリに別のBouncerServiceProviderクラスを作成できます ( providers構成配列に忘れずに登録してください)。
デフォルトでは、Bouncer によって実行されたすべてのクエリは現在のリクエストに対してキャッシュされます。パフォーマンスを向上させるために、クロスリクエスト キャッシュを使用することもできます。
Bouncer:: cache ();警告:クロスリクエスト キャッシュを有効にした場合、ユーザーの役割/能力を変更するたびにキャッシュを更新する必要があります。キャッシュを更新する方法については、「キャッシュを更新する」を参照してください。
逆に、同じリクエスト内であってもキャッシュを完全に無効にしたい場合があります。
Bouncer:: dontCache ();これは、単体テストで、付与されたばかりのロール/能力に対してアサーションを実行する場合に特に便利です。
Bouncer で使用されるデータベース テーブル名を変更するには、連想配列をtablesメソッドに渡します。キーはバウンサーのデフォルトのテーブル名である必要があり、値は使用するテーブル名である必要があります。すべてのテーブル名を渡す必要はありません。変更したいもののみ。
Bouncer:: tables ([
' abilities ' => ' my_abilities ' ,
' permissions ' => ' granted_abilities ' ,
]);Bouncer の公開された移行では、この構成のテーブル名が使用されるため、実際に移行を実行する前に、これらのテーブル名を必ず設定してください。
Bouncer の組み込みのRoleとAbilityモデルを簡単に拡張できます。
namespace App Models ;
use Silber Bouncer Database Ability as BouncerAbility ;
class Ability extends BouncerAbility
{
// custom code
} namespace App Models ;
use Silber Bouncer Database Role as BouncerRole ;
class Role extends BouncerRole
{
// custom code
}あるいは、Bouncer のモデルを実際に拡張せずに、Bouncer のIsAbilityおよびIsRole特性を使用することもできます。
namespace App Models ;
use Illuminate Database Eloquent Model ;
use Silber Bouncer Database Concerns IsAbility ;
class Ability extends Model
{
use IsAbility;
// custom code
} namespace App Models ;
use Illuminate Database Eloquent Model ;
use Silber Bouncer Database Concerns IsRole ;
class Role extends Model
{
use IsRole;
// custom code
} Bouncer のモデルを拡張する代わりに特性を使用する場合は、適切な$table名と$fillableフィールドを自分で設定してください。
どの方法を使用するかに関係なく、次のステップは実際に Bouncer にカスタム モデルを使用するように指示することです。
Bouncer:: useAbilityModel ( App Models Ability::class);
Bouncer:: useRoleModel ( App Models Role::class);注: Eloquent は、親モデル名に基づいてリレーションシップの外部キーを決定します (Eloquent のドキュメントを参照)。物事をシンプルにするために、カスタム クラスに Bouncer と同じ名前を付けます: それぞれ、
AbilityとRoleです。別の名前を使用する必要がある場合は、必ず移行ファイルを更新するか、関係メソッドをオーバーライドして外部キーを明示的に設定してください。
デフォルトでは、Bouncer はデフォルトの認証ガードのユーザー モデルを自動的に使用します。
デフォルト以外のガードで Bouncer を使用しており、別のユーザー モデルを使用している場合は、使用したいユーザー モデルを Bouncer に通知する必要があります。
Bouncer:: useUserModel ( App Admin::class);Bouncer では、所有権の概念を使用して、ユーザーが「所有している」モデルに対してアクションを実行できるようにします。
デフォルトでは、Bouncer はモデルのuser_id現在のユーザーの主キーと照合してチェックします。必要に応じて、これを別の属性に設定できます。
Bouncer:: ownedVia ( ' userId ' );異なるモデルが所有権に異なる列を使用する場合は、それらを個別に登録できます。
Bouncer:: ownedVia (Post::class, ' created_by ' );
Bouncer:: ownedVia (Order::class, ' entered_by ' );より詳細に制御するには、カスタム ロジックを使用してクロージャを渡すことができます。
Bouncer:: ownedVia (Game::class, function ( $ game , $ user ) {
return $ game -> team_id == $ user -> team_id ;
});Bouncer には、人々から頻繁に質問される概念がいくつかあります。ここでは、それらのトピックのいくつかの短いリストを示します。
初期のロールと能力のシードは、通常の Laravel シーダー クラスで行うことができます。まず、Bouncer 用の特定のシーダー ファイルを作成します。
php artisan make:seeder BouncerSeeder
シードの役割と能力のコードをすべてシーダーのrunメソッドに配置します。以下にその例を示します。
use Bouncer ;
use Illuminate Database Seeder ;
class BouncerSeeder extends Seeder
{
public function run ()
{
Bouncer:: allow ( ' superadmin ' )-> everything ();
Bouncer:: allow ( ' admin ' )-> everything ();
Bouncer:: forbid ( ' admin ' )-> toManage (User::class);
Bouncer:: allow ( ' editor ' )-> to ( ' create ' , Post::class);
Bouncer:: allow ( ' editor ' )-> toOwn (Post::class);
// etc.
}
}実際に実行するには、シーダーのクラス名をdb:seedコマンドのclassオプションに渡します。
php artisan db:seed --class=BouncerSeeder
バウンサーのscope使用してサイトのさまざまな部分を分割し、それぞれに独自の役割と能力のセットを持つサイロを作成できます。
$identifier取得し、それを現在のスコープとして設定するScopeBouncerミドルウェアを作成します。
use Bouncer , Closure ;
class ScopeBouncer
{
public function handle ( $ request , Closure $ next , $ identifier )
{
Bouncer:: scope ()-> to ( $ identifier );
return $ next ( $ request );
}
}この新しいミドルウェアをルート ミドルウェアとして HTTP カーネル クラスに登録します。
protected $ routeMiddleware = [
// Keep the other route middleware, and add this:
' scope-bouncer ' => App Http Middleware ScopeBouncer::class,
];ルート サービス プロバイダーで、パブリック ルートとダッシュボード ルートにそれぞれ異なる識別子を使用してこのミドルウェアを適用します。
Route:: middleware ([ ' web ' , ' scope-bouncer:1 ' ])
-> namespace ( $ this -> namespace )
-> group ( base_path ( ' routes/public.php ' ));
Route:: middleware ([ ' web ' , ' scope-bouncer:2 ' ])
-> namespace ( $ this -> namespace )
-> group ( base_path ( ' routes/dashboard.php ' ));それでおしまい。すべての役割と能力は、サイトの各セクションに個別に適用されるようになります。スコープの範囲を微調整するには、「バウンサーのスコープのカスタマイズ」を参照してください。
Laravel 5.4 以降、デフォルトのデータベース文字セットはutf8mb4なりました。 Laravel 5.4 以降で一部のデータベースの古いバージョン (MySQL 5.7.7 未満、または MariaDB 10.2.2 未満) を使用している場合、文字列列にインデックスを作成しようとすると SQL エラーが発生します。これを修正するには、 AppServiceProviderで Laravel のデフォルトの文字列長を変更します。
use Illuminate Support Facades Schema ;
public function boot ()
{
Schema:: defaultStringLength ( 191 );
}詳細については、この Laravel ニュース記事をご覧ください。
JSON カラムは、MySQL (5.7.8) および MariaDB (10.2.7) に比較的新しく追加されました。これらのデータベースの古いバージョンを使用している場合は、JSON 列を使用できません。
最善の解決策は、DB をアップグレードすることです。現在それが不可能な場合は、代わりにtext列を使用するように公開された移行ファイルを変更できます。
- $table->json('options')->nullable();
+ $table->text('options')->nullable(); bouncer:clean bouncer:cleanコマンドは、未使用のアビリティを削除します。このコマンドを実行すると、2 種類の未使用のアビリティが削除されます。
未割り当ての能力- 誰にも割り当てられていない能力。例えば：
Bouncer:: allow ( $ user )-> to ( ' view ' , Plan::class);
Bouncer:: disallow ( $ user )-> to ( ' view ' , Plan::class);この時点では、「プランの表示」機能は誰にも割り当てられていないため、削除されます。
注: アプリのコンテキストによっては、これらを削除したくない場合があります。ユーザーがアプリの UI で能力を管理できるようにする場合、おそらく、未割り当ての能力を削除したくないでしょう。以下を参照してください。
孤立した能力- モデルが削除されたモデル能力:
Bouncer:: allow ( $ user )-> to ( ' delete ' , $ plan );
$ plan -> delete ();計画が存在しなくなったため、能力は役に立たなくなり、削除されます。
1 種類の未使用の能力のみを削除する場合は、次のいずれかのフラグを使用して実行します。
php artisan bouncer:clean --unassigned
php artisan bouncer:clean --orphaned
フラグを渡さない場合は、両方のタイプの未使用の能力が削除されます。
このコマンドを定期的に自動的に実行するには、コンソール カーネルのスケジュールに追加します。
$ schedule -> command ( ' bouncer:clean ' )-> weekly (); // Adding abilities for users
Bouncer:: allow ( $ user )-> to ( ' ban-users ' );
Bouncer:: allow ( $ user )-> to ( ' edit ' , Post::class);
Bouncer:: allow ( $ user )-> to ( ' delete ' , $ post );
Bouncer:: allow ( $ user )-> everything ();
Bouncer:: allow ( $ user )-> toManage (Post::class);
Bouncer:: allow ( $ user )-> toManage ( $ post );
Bouncer:: allow ( $ user )-> to ( ' view ' )-> everything ();
Bouncer:: allow ( $ user )-> toOwn (Post::class);
Bouncer:: allow ( $ user )-> toOwnEverything ();
// Removing abilities uses the same syntax, e.g.
Bouncer:: disallow ( $ user )-> to ( ' delete ' , $ post );
Bouncer:: disallow ( $ user )-> toManage (Post::class);
Bouncer:: disallow ( $ user )-> toOwn (Post::class);
// Adding & removing abilities for roles
Bouncer:: allow ( ' admin ' )-> to ( ' ban-users ' );
Bouncer:: disallow ( ' admin ' )-> to ( ' ban-users ' );
// You can also forbid specific abilities with the same syntax...
Bouncer:: forbid ( $ user )-> to ( ' delete ' , $ post );
// And also remove a forbidden ability with the same syntax...
Bouncer:: unforbid ( $ user )-> to ( ' delete ' , $ post );
// Re-syncing a user's abilities
Bouncer:: sync ( $ user )-> abilities ( $ abilities );
// Assigning & retracting roles from users
Bouncer:: assign ( ' admin ' )-> to ( $ user );
Bouncer:: retract ( ' admin ' )-> from ( $ user );
// Assigning roles to multiple users by ID
Bouncer:: assign ( ' admin ' )-> to ([ 1 , 2 , 3 ]);
// Re-syncing a user's roles
Bouncer:: sync ( $ user )-> roles ( $ roles );
// Checking the current user's abilities
$ boolean = Bouncer:: can ( ' ban-users ' );
$ boolean = Bouncer:: can ( ' edit ' , Post::class);
$ boolean = Bouncer:: can ( ' delete ' , $ post );
$ boolean = Bouncer:: cannot ( ' ban-users ' );
$ boolean = Bouncer:: cannot ( ' edit ' , Post::class);
$ boolean = Bouncer:: cannot ( ' delete ' , $ post );
// Checking a user's roles
$ boolean = Bouncer:: is ( $ user )-> a ( ' subscriber ' );
$ boolean = Bouncer:: is ( $ user )-> an ( ' admin ' );
$ boolean = Bouncer:: is ( $ user )-> notA ( ' subscriber ' );
$ boolean = Bouncer:: is ( $ user )-> notAn ( ' admin ' );
$ boolean = Bouncer:: is ( $ user )-> a ( ' moderator ' , ' editor ' );
$ boolean = Bouncer:: is ( $ user )-> all ( ' moderator ' , ' editor ' );
Bouncer:: cache ();
Bouncer:: dontCache ();
Bouncer:: refresh ();
Bouncer:: refreshFor ( $ user );この機能の一部は、ユーザー モデルでも直接利用できます。
$ user -> allow ( ' ban-users ' );
$ user -> allow ( ' edit ' , Post::class);
$ user -> allow ( ' delete ' , $ post );
$ user -> disallow ( ' ban-users ' );
$ user -> disallow ( ' edit ' , Post::class);
$ user -> disallow ( ' delete ' , $ post );
$ user -> assign ( ' admin ' );
$ user -> retract ( ' admin ' );
$ boolean = $ user -> isAn ( ' admin ' );
$ boolean = $ user -> isAn ( ' editor ' , ' moderator ' );
$ boolean = $ user -> isAll ( ' moderator ' , ' editor ' );
$ boolean = $ user -> isNotAn ( ' admin ' , ' moderator ' );
// Querying users by their roles
$ users = User:: whereIs ( ' superadmin ' )-> get ();
$ users = User:: whereIs ( ' superadmin ' , ' admin ' )-> get ();
$ users = User:: whereIsAll ( ' sales ' , ' marketing ' )-> get ();
$ abilities = $ user -> getAbilities ();
$ forbidden = $ user -> getForbiddenAbilities ();Spatie が親切にもコミュニティに提供した数十億個のパッケージの中には、優れた laravel-permission パッケージが含まれています。 Bouncer と同様に、Laravel の組み込みゲートと権限チェックとうまく統合されていますが、構文、DB 構造、機能に関しては異なる設計の選択肢があります。
Bouncer は、MIT ライセンスに基づいてライセンスされたオープンソース ソフトウェアです
