bouncer
v1.0.2
Bouncer는 Eloquent 모델을 사용하여 모든 앱의 역할과 능력을 관리하는 우아하고 프레임워크에 구애받지 않는 접근 방식입니다.
bouncer:cleanBouncer는 Eloquent 모델을 사용하여 모든 앱의 역할과 능력을 관리하는 우아하고 프레임워크에 구애받지 않는 접근 방식입니다. 표현력이 풍부하고 유창한 구문을 사용하면 최대한 방해가 되지 않습니다. 원할 때는 사용하고 원치 않을 때는 무시하세요.
Bouncer의 기능을 빠르고 한눈에 살펴보려면 치트 시트를 확인하세요.
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을 사용하세요.
작곡가와 함께 Bouncer를 설치하십시오.
composer require silber/bouncer
사용자 모델에 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 Facades에 대한 자세한 내용은 Laravel 설명서를 참조하세요.
작곡가와 함께 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을 실행할 수 있습니다.
사용자 모델에 Bouncer의 특성을 추가하세요.
use Illuminate Database Eloquent Model ;
use Silber Bouncer Database HasRolesAndAbilities ;
class User extends Model
{
use HasRolesAndAbilities;
}Bouncer 인스턴스를 만듭니다.
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 필요로 하는 모든 클래스에 주입할 수 있습니다.
create 메소드는 적절한 기본값을 사용하여 Bouncer 인스턴스를 생성합니다. 완전히 사용자 정의하려면 make 메소드를 사용하여 팩토리 인스턴스를 가져오십시오. Bouncer 인스턴스를 생성하려면 팩토리에서 create() 호출하세요.
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 ' ); 그게 다야. 뒤에서 Bouncer는 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 ' );때로는 특정 모델 유형으로 기능을 제한하고 싶을 수도 있습니다. 모델 이름을 두 번째 인수로 전달하기만 하면 됩니다.
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 ' );특정 모델 유형에 대한 기능을 제거하려면 해당 이름을 두 번째 인수로 전달하세요.
Bouncer:: disallow ( $ user )-> to ( ' delete ' , Post::class);경고: 사용자가 특정
$post인스턴스를delete수 있는 능력이 있는 경우 위의 코드는 해당 능력을 제거하지 않습니다 . 아래와 같이 실제$post두 번째 인수로 전달하여 기능을 별도로 제거해야 합니다.
특정 모델 인스턴스에 대한 기능을 제거하려면 대신 실제 모델을 전달하세요.
Bouncer:: disallow ( $ user )-> to ( ' delete ' , $ post );참고 :
disallow메소드는 이전에 이 사용자/역할에 부여된 능력만 제거합니다. 보다 일반적인 능력이 허용한 것의 일부를 허용하지 않으려면forbid방법을 사용하세요.
Bouncer를 사용하면 더 세밀한 제어를 위해 특정 능력을 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를 사용자 정의할 수 있습니다.
이러한 구성 옵션 중 하나 또는 두 개만 사용하는 경우 해당 옵션을 기본 AppServiceProvider 의 boot 방법에 추가할 수 있습니다. 커지기 시작하면 app/Providers 디렉토리에 별도의 BouncerServiceProvider 클래스를 생성할 수 있습니다( providers 구성 배열에 등록하는 것을 기억하세요).
기본적으로 Bouncer가 실행한 모든 쿼리는 현재 요청에 대해 캐시됩니다. 더 나은 성능을 위해 교차 요청 캐싱을 사용할 수 있습니다.
Bouncer:: cache ();경고: 교차 요청 캐싱을 활성화한 경우 사용자의 역할/능력을 변경할 때마다 캐시를 새로 고쳐야 합니다. 캐시를 새로 고치는 방법은 캐시 새로 고침을 읽어보세요.
반대로 동일한 요청 내에서도 캐시를 완전히 비활성화하고 싶을 수도 있습니다.
Bouncer:: dontCache ();이는 방금 부여된 역할/능력에 대해 어설션을 실행하려는 경우 단위 테스트에서 특히 유용합니다.
Bouncer에서 사용하는 데이터베이스 테이블 이름을 변경하려면 tables 메소드에 연관 배열을 전달하십시오. 키는 Bouncer의 기본 테이블 이름이어야 하며 값은 사용하려는 테이블 이름이어야 합니다. 모든 테이블 이름을 전달할 필요는 없습니다. 변경하려는 항목만.
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
Bouncer의 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 ' ));그게 다야. 이제 모든 역할과 능력은 사이트의 각 섹션에 대해 별도로 범위가 지정됩니다. 범위 범위를 미세 조정하려면 Bouncer 범위 사용자 정의를 참조하세요.
Laravel 5.4부터 기본 데이터베이스 문자 집합은 이제 utf8mb4 입니다. Laravel 5.4+와 함께 일부 데이터베이스(5.7.7 이하의 MySQL 또는 10.2.2 이하의 MariaDB)의 이전 버전을 사용하는 경우 문자열 열에 인덱스를 생성하려고 하면 SQL 오류가 발생합니다. 이 문제를 해결하려면 AppServiceProvider 에서 Laravel의 기본 문자열 길이를 변경하세요.
use Illuminate Support Facades Schema ;
public function boot ()
{
Schema:: defaultStringLength ( 191 );
}자세한 내용은 Laravel News 기사에서 확인하실 수 있습니다.
JSON 열은 MySQL(5.7.8) 및 MariaDB(10.2.7)에 비교적 새로 추가된 항목입니다. 이러한 데이터베이스의 이전 버전을 사용하는 경우 JSON 열을 사용할 수 없습니다.
가장 좋은 해결책은 DB를 업그레이드하는 것입니다. 현재 가능하지 않은 경우 대신 text 열을 사용하도록 게시된 마이그레이션 파일을 변경할 수 있습니다.
- $table->json('options')->nullable();
+ $table->text('options')->nullable(); bouncer:clean bouncer:clean 명령은 사용하지 않는 능력을 삭제합니다. 이 명령을 실행하면 사용하지 않는 두 가지 유형의 능력이 삭제됩니다.
할당되지 않은 능력 - 누구에게도 할당되지 않은 능력입니다. 예를 들어:
Bouncer:: allow ( $ user )-> to ( ' view ' , Plan::class);
Bouncer:: disallow ( $ user )-> to ( ' view ' , Plan::class);이 시점에서는 "계획 보기" 기능이 누구에게도 할당되지 않으므로 삭제됩니다.
참고 : 앱의 상황에 따라 삭제하지 않을 수도 있습니다. 사용자가 앱 UI에서 기능을 관리하도록 허용하는 경우 할당되지 않은 기능을 삭제하고 싶지 않을 것입니다. 아래를 참조하세요.
고아 능력 - 모델이 삭제된 모델 능력:
Bouncer:: allow ( $ user )-> to ( ' delete ' , $ plan );
$ plan -> delete ();계획이 더 이상 존재하지 않으므로 해당 기능은 더 이상 사용되지 않으므로 삭제됩니다.
사용하지 않는 한 가지 유형의 능력만 삭제하려면 다음 플래그 중 하나를 사용하여 실행하세요.
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 라이선스에 따라 라이선스가 부여된 오픈 소스 소프트웨어입니다.
