مجوز

• معرفی
• دروازه ها
  • گیتس نوشتن
  • اعمال مجوز
  • پاسخ های گیت
  • رهگیری چک های دروازه
• ایجاد سیاست ها
  • ایجاد سیاست ها
  • سیاست های ثبت نام
• سیاست های نوشتن
  • روش های سیاست گذاری
  • پاسخ های خط مشی
  • روش‌های بدون مدل
  • کاربران مهمان
  • فیلترهای خط مشی
• مجوز اقدامات با استفاده از خط مشی ها
  • از طریق مدل کاربر
  • از طریق Middleware
  • از طریق Controller Helpers
  • از طریق قالب های Blade
  • ارائه متن اضافی

معرفی

لاراول علاوه بر ارائه خدمات احراز هویت خارج از جعبه، راه ساده ای نیز برای مجوز دادن به اقدامات کاربر در برابر یک منبع داده شده ارائه می دهد. مانند احراز هویت، رویکرد لاراول به مجوز ساده است و دو راه اصلی برای مجوز دادن به اقدامات وجود دارد: دروازه‌ها و سیاست‌ها.

به دروازه ها و سیاست هایی مانند مسیرها و کنترلرها فکر کنید. گیتس یک رویکرد ساده و مبتنی بر بسته شدن را برای مجوز ارائه می دهد در حالی که سیاست ها، مانند کنترلرها، منطق خود را حول یک مدل یا منبع خاص گروه بندی می کنند. ابتدا گیت ها را بررسی می کنیم و سپس سیاست ها را بررسی می کنیم.

شما نیازی به انتخاب بین استفاده انحصاری از گیت ها یا استفاده انحصاری از سیاست ها در هنگام ساختن یک برنامه ندارید. اکثر برنامه ها به احتمال زیاد حاوی ترکیبی از گیت ها و سیاست ها هستند، و این کاملاً خوب است! گیت ها برای اقداماتی که به هیچ مدل یا منبعی مرتبط نیستند، مانند مشاهده داشبورد سرپرست، بیشتر کاربرد دارند. در مقابل، زمانی که می‌خواهید برای یک مدل یا منبع خاص مجوز انجام دهید، باید از خط‌مشی‌ها استفاده شود.

دروازه ها

گیتس نوشتن

گیت ها بسته هایی هستند که تعیین می کنند آیا کاربر مجاز به انجام یک عمل خاص است و معمولاً در App\Providers\AuthServiceProvider کلاس با استفاده از Gate نما تعریف می شوند. گیت ها همیشه یک نمونه کاربر را به عنوان اولین آرگومان دریافت می کنند و ممکن است به صورت اختیاری آرگومان های اضافی مانند مدل Eloquent مربوطه را دریافت کنند:

/**
 * Register any authentication / authorization services.
 *
 * @return void
 */
public function boot()
{
    $this->registerPolicies();
 
    Gate::define('edit-settings', function ($user) {
        return $user->isAdmin;
    });
 
    Gate::define('update-post', function ($user, $post) {
        return $user->id === $post->user_id;
    });
}

Class@method گیت ها همچنین ممکن است با استفاده از یک رشته استایل برگشتی مانند کنترلرها تعریف شوند :

/**
 * Register any authentication / authorization services.
 *
 * @return void
 */
public function boot()
{
    $this->registerPolicies();
 
    Gate::define('update-post', 'App\Policies\PostPolicy@update');
}

اعمال مجوز

برای مجاز کردن یک اقدام با استفاده از گیت‌ها، باید از روش‌های allows یا استفاده کنید denies . توجه داشته باشید که لازم نیست کاربر تأیید شده فعلی را به این روش ها منتقل کنید. لاراول به طور خودکار از عبور دادن کاربر به دروازه بسته شدن مراقبت می کند:

if (Gate::allows('edit-settings')) {
    // The current user can edit settings
}
 
if (Gate::allows('update-post', $post)) {
    // The current user can update the post...
}
 
if (Gate::denies('update-post', $post)) {
    // The current user can't update the post...
}

اگر می خواهید تعیین کنید که آیا یک کاربر خاص مجاز به انجام یک عمل است، می توانید از forUser روش روی Gate نما استفاده کنید:

if (Gate::forUser($user)->allows('update-post', $post)) {
    // The user can update the post...
}
 
if (Gate::forUser($user)->denies('update-post', $post)) {
    // The user can't update the post...
}

می‌توانید همزمان چندین اقدام را با روش‌های any زیر مجاز کنید none :

if (Gate::any(['update-post', 'delete-post'], $post)) {
    // The user can update or delete the post
}
 
if (Gate::none(['update-post', 'delete-post'], $post)) {
    // The user cannot update or delete the post
}

مجوز یا پرتاب استثناها

اگر می‌خواهید اقدامی را مجاز کنید و Illuminate\Auth\Access\AuthorizationException اگر کاربر مجاز به انجام آن عمل نباشد، به طور خودکار یک علامت را پرتاب کنید، می‌توانید از این Gate::authorize روش استفاده کنید. نمونه هایی از AuthorizationException به طور خودکار به 403 پاسخ HTTP تبدیل می شوند:

Gate::authorize('update-post', $post);
 
// The action is authorized...

ارائه متن اضافی

متدهای گیت برای مجاز کردن توانایی ها ( ،،،،،،،،،، ) allows و دستورالعمل های مجوز Blade ( ،،، ) می توانند آرایه ای را به عنوان آرگومان دوم دریافت کنند . این عناصر آرایه به‌عنوان پارامترهایی به گیت ارسال می‌شوند و می‌توانند برای زمینه اضافی هنگام تصمیم‌گیری مجوز استفاده شوند: denies check any none authorize can cannot @can @cannot @canany

Gate::define('create-post', function ($user, $category, $extraFlag) {
    return $category->group > 3 && $extraFlag === true;
});
 
if (Gate::check('create-post', [$category, $extraFlag])) {
    // The user can create the post...
}

پاسخ های گیت

تا اینجا ما فقط گیت هایی را بررسی کرده ایم که مقادیر ساده بولی را برمی گرداند. با این حال، گاهی اوقات ممکن است بخواهید پاسخ دقیق تری، از جمله یک پیام خطا، بازگردانید. برای انجام این کار، می توانید یک عدد Illuminate\Auth\Access\Response از دروازه خود برگردانید:

use Illuminate\Auth\Access\Response;
use Illuminate\Support\Facades\Gate;
 
Gate::define('edit-settings', function ($user) {
    return $user->isAdmin
                ? Response::allow()
                : Response::deny('You must be a super administrator.');
});

هنگام برگرداندن پاسخ مجوز از گیت شما، Gate::allows روش همچنان یک مقدار بولی ساده را برمی گرداند. با این حال، می توانید از Gate::inspect روش برای دریافت پاسخ مجوز کامل توسط گیت استفاده کنید:

$response = Gate::inspect('edit-settings', $post);
 
if ($response->allowed()) {
    // The action is authorized...
} else {
    echo $response->message();
}

البته، هنگام استفاده از Gate::authorize روش پرتاب an AuthorizationException در صورتی که اقدام مجاز نباشد، پیام خطای ارائه شده توسط پاسخ مجوز به پاسخ HTTP منتشر می شود:

Gate::authorize('edit-settings', $post);
 
// The action is authorized...

رهگیری چک های دروازه

گاهی اوقات، ممکن است بخواهید تمام توانایی ها را به یک کاربر خاص اعطا کنید. می‌توانید از این before روش برای تعریف تماس برگشتی استفاده کنید که قبل از سایر بررسی‌های مجوز اجرا می‌شود:

Gate::before(function ($user, $ability) {
    if ($user->isSuperAdmin()) {
        return true;
    }
});

اگر before فراخوان یک نتیجه غیر تهی را برگرداند، آن نتیجه به عنوان نتیجه بررسی در نظر گرفته می شود.

می‌توانید از این after روش برای تعریف یک بازخوانی استفاده کنید تا پس از بررسی‌های دیگر مجوز اجرا شود:

Gate::after(function ($user, $ability, $result, $arguments) {
    if ($user->isSuperAdmin()) {
        return true;
    }
});

مشابه before چک، اگر after فراخوان یک نتیجه غیر تهی برگرداند، آن نتیجه نتیجه چک در نظر گرفته می شود.

ایجاد سیاست ها

ایجاد سیاست ها

سیاست ها کلاس هایی هستند که منطق مجوز را حول یک مدل یا منبع خاص سازماندهی می کنند. به عنوان مثال، اگر برنامه شما یک وبلاگ است، ممکن است یک Post مدل و متناظر PostPolicy برای مجاز کردن اقدامات کاربر مانند ایجاد یا به‌روزرسانی پست‌ها داشته باشید.

می توانید با استفاده از make:policy دستور artisan یک خط مشی ایجاد کنید . خط مشی ایجاد شده در app/Policies دایرکتوری قرار می گیرد. اگر این دایرکتوری در برنامه شما وجود نداشته باشد، لاراول آن را برای شما ایجاد می کند:

php artisan make:policy PostPolicy

این make:policy دستور یک کلاس سیاست خالی ایجاد می کند. اگر می‌خواهید یک کلاس با روش‌های خط‌مشی اصلی «CRUD» که قبلاً در کلاس گنجانده شده است ایجاد کنید، می‌توانید --model هنگام اجرای دستور، a را مشخص کنید:

php artisan make:policy PostPolicy --model=Post

تمام خط مشی ها از طریق کانتینر سرویس لاراول حل می شوند و به شما این امکان را می دهند که هر وابستگی مورد نیاز را در سازنده خط مشی تایپ کنید تا به طور خودکار آنها را تزریق کنید.

سیاست های ثبت نام

هنگامی که سیاست وجود دارد، باید ثبت شود. برنامه‌های AuthServiceProvider جدید لاراول شامل policies ویژگی‌هایی هستند که مدل‌های Eloquent شما را با خط‌مشی‌های مربوطه خود ترسیم می‌کند. ثبت یک خط‌مشی به لاراول دستور می‌دهد که از کدام خط‌مشی برای تأیید اقدامات علیه یک مدل خاص استفاده کند:

<?php
 
namespace App\Providers;
 
use App\Policies\PostPolicy;
use App\Post;
use Illuminate\Foundation\Support\Providers\AuthServiceProvider as ServiceProvider;
use Illuminate\Support\Facades\Gate;
 
class AuthServiceProvider extends ServiceProvider
{
    /**
     * The policy mappings for the application.
     *
     * @var array
     */
    protected $policies = [
        Post::class => PostPolicy::class,
    ];
 
    /**
     * Register any application authentication / authorization services.
     *
     * @return void
     */
    public function boot()
    {
        $this->registerPolicies();
 
        //
    }
}

کشف خودکار خط مشی

به‌جای ثبت دستی خط‌مشی‌های مدل، لاراول می‌تواند خط‌مشی‌ها را به‌طور خودکار کشف کند تا زمانی که مدل و خط‌مشی از قراردادهای نام‌گذاری استاندارد لاراول پیروی کنند. به طور خاص، سیاست ها باید در Policies دایرکتوری زیر دایرکتوری حاوی مدل ها باشند. بنابراین، برای مثال، مدل‌ها ممکن است در app فهرست قرار گیرند، در حالی که سیاست‌ها ممکن است در app/Policies فهرست قرار گیرند. علاوه بر این، نام خط مشی باید با نام مدل مطابقت داشته باشد و دارای Policy پسوند باشد. بنابراین، یک User مدل با یک کلاس مطابقت دارد UserPolicy .

اگر می‌خواهید منطق کشف خط‌مشی خود را ارائه دهید، می‌توانید با استفاده از این Gate::guessPolicyNamesUsing روش، یک پاسخ تماس سفارشی ثبت کنید. boot به طور معمول، این متد باید از روش برنامه شما فراخوانی شود AuthServiceProvider :

use Illuminate\Support\Facades\Gate;
 
Gate::guessPolicyNamesUsing(function ($modelClass) {
    // return policy class name...
});

هر خط‌مشی که به صراحت در شما ترسیم شده است، AuthServiceProvider بر هر خط‌مشی بالقوه کشف شده خودکار اولویت دارد.

سیاست های نوشتن

روش های سیاست گذاری

هنگامی که خط مشی ثبت شد، می توانید روش هایی را برای هر اقدامی که مجوز می دهد اضافه کنید. به عنوان مثال، بیایید update روشی را در خود تعریف کنیم PostPolicy که تعیین می کند آیا یک داده می تواند یک نمونه User معین را به روز کند یا خیر . Post

این متد یک و یک نمونه را به عنوان آرگومان های خود update دریافت می کند و باید برگردد یا نشان دهد که آیا کاربر مجاز به به روز رسانی داده شده است یا خیر . بنابراین، برای این مثال، اجازه دهید بررسی کنیم که کاربر با پست مطابقت دارد : User Post true false Post id user_id

<?php
 
namespace App\Policies;
 
use App\Post;
use App\User;
 
class PostPolicy
{
    /**
     * Determine if the given post can be updated by the user.
     *
     * @param  \App\User  $user
     * @param  \App\Post  $post
     * @return bool
     */
    public function update(User $user, Post $post)
    {
        return $user->id === $post->user_id;
    }
}

می‌توانید به تعریف روش‌های اضافی روی خط‌مشی در صورت نیاز برای اقدامات مختلفی که مجوز می‌دهد، ادامه دهید. برای مثال، ممکن است روش‌هایی را برای مجوز دادن به اقدامات مختلف تعریف کنید view ، delete اما Post به یاد داشته باشید که می‌توانید به روش‌های خط‌مشی خود هر نامی که دوست دارید بدهید.

اگر --model هنگام ایجاد خط‌مشی خود از طریق کنسول Artisan از این گزینه استفاده کرده‌اید، از قبل حاوی روش‌هایی برای viewAny , view , create , update , delete , restore و forceDelete اقدامات است.

پاسخ های خط مشی

تا کنون، ما فقط روش‌های سیاستی را بررسی کرده‌ایم که مقادیر بولی ساده را برمی‌گردانند. با این حال، گاهی اوقات ممکن است بخواهید پاسخ دقیق تری، از جمله یک پیام خطا، بازگردانید. برای انجام این کار، می توانید Illuminate\Auth\Access\Response از روش خط مشی خود یک عدد را برگردانید:

use Illuminate\Auth\Access\Response;
 
/**
 * Determine if the given post can be updated by the user.
 *
 * @param  \App\User  $user
 * @param  \App\Post  $post
 * @return \Illuminate\Auth\Access\Response
 */
public function update(User $user, Post $post)
{
    return $user->id === $post->user_id
                ? Response::allow()
                : Response::deny('You do not own this post.');
}

هنگام برگرداندن پاسخ مجوز از خط مشی شما، Gate::allows روش همچنان یک مقدار بولی ساده را برمی گرداند. با این حال، می توانید از Gate::inspect روش برای دریافت پاسخ مجوز کامل توسط گیت استفاده کنید:

$response = Gate::inspect('update', $post);
 
if ($response->allowed()) {
    // The action is authorized...
} else {
    echo $response->message();
}

البته، هنگام استفاده از Gate::authorize روش پرتاب an AuthorizationException در صورتی که اقدام مجاز نباشد، پیام خطای ارائه شده توسط پاسخ مجوز به پاسخ HTTP منتشر می شود:

Gate::authorize('update', $post);
 
// The action is authorized...

روش‌های بدون مدل

برخی از روش‌های خط‌مشی فقط کاربر تأیید شده فعلی را دریافت می‌کنند و نمونه‌ای از مدلی را که مجاز کرده‌اند دریافت نمی‌کنند. این وضعیت در هنگام مجوز دادن به اقدامات رایج است create . به عنوان مثال، اگر در حال ایجاد یک وبلاگ هستید، ممکن است بخواهید بررسی کنید که آیا کاربر اصلاً مجاز به ایجاد هرگونه پست است یا خیر.

هنگام تعریف روش‌های خط‌مشی که نمونه‌ای از مدل را دریافت نمی‌کنند، مانند روش create ، نمونه‌ای از مدل را دریافت نمی‌کند. در عوض، شما باید روش را طوری تعریف کنید که فقط از کاربر تأیید شده انتظار دارد:

/**
 * Determine if the given user can create posts.
 *
 * @param  \App\User  $user
 * @return bool
 */
public function create(User $user)
{
    //
}

کاربران مهمان

به‌طور پیش‌فرض، false اگر درخواست HTTP دریافتی توسط کاربر احراز هویت شده آغاز نشده باشد، همه گیت‌ها و خط‌مشی‌ها به‌طور خودکار برمی‌گردند. null با این حال، می‌توانید با اعلام یک نوع اشاره «اختیاری» یا ارائه یک مقدار پیش‌فرض برای تعریف آرگومان کاربر، اجازه دهید این بررسی‌های مجوز به گیت‌ها و خط‌مشی‌های شما منتقل شوند :

<?php
 
namespace App\Policies;
 
use App\Post;
use App\User;
 
class PostPolicy
{
    /**
     * Determine if the given post can be updated by the user.
     *
     * @param  \App\User  $user
     * @param  \App\Post  $post
     * @return bool
     */
    public function update(?User $user, Post $post)
    {
        return optional($user)->id === $post->user_id;
    }
}

فیلترهای خط مشی

برای کاربران خاصی، ممکن است بخواهید همه اقدامات را در یک خط مشی مشخص مجاز کنید. برای انجام این کار، before روشی را روی خط مشی تعریف کنید. این before متد قبل از هر روش دیگری در خط مشی اجرا می شود و به شما فرصتی می دهد تا قبل از فراخوانی روش سیاست مورد نظر، اقدام را مجاز کنید. این ویژگی بیشتر برای اجازه دادن به مدیران برنامه برای انجام هر عملی استفاده می شود:

public function before($user, $ability)
{
    if ($user->isSuperAdmin()) {
        return true;
    }
}

اگر می خواهید همه مجوزها را برای یک کاربر رد کنید، باید false از before روش برگردید. اگر null بازگردانده شود، مجوز از طریق روش سیاست قرار می گیرد.

before اگر کلاس حاوی متدی با نامی مطابق با نام توانایی در حال بررسی نباشد، متد یک کلاس سیاست فراخوانی نخواهد شد .

مجوز اقدامات با استفاده از خط مشی ها

از طریق مدل کاربر

مدلی User که در برنامه لاراول شما گنجانده شده است شامل دو روش مفید برای مجوز دادن به اقدامات است: can و cant . متد can اقدامی را که می‌خواهید مجاز کنید و مدل مربوطه را دریافت می‌کند. به عنوان مثال، اجازه دهید تعیین کنیم که آیا کاربر مجاز به به روز رسانی یک Post مدل معین است یا خیر:

if ($user->can('update', $post)) {
    //
}

اگر یک خط مشی برای مدل داده شده ثبت شود can ، متد به طور خودکار خط مشی مناسب را فراخوانی می کند و نتیجه بولی را برمی گرداند. اگر هیچ خط مشی برای مدل ثبت نشده باشد، این can روش سعی می کند دروازه مبتنی بر بسته شدن را که با نام عمل داده شده مطابقت دارد فراخوانی کند.

اقداماتی که به مدل نیاز ندارند

به یاد داشته باشید، برخی از اقدامات مانند create ممکن است نیازی به یک نمونه مدل نداشته باشند. در این مواقع، می توانید نام کلاس را به can متد ارسال کنید. از نام کلاس برای تعیین اینکه از کدام خط مشی هنگام مجوز دادن به عملکرد استفاده شود استفاده می شود:

use App\Post;
 
if ($user->can('create', Post::class)) {
    // Executes the "create" method on the relevant policy...
}

از طریق Middleware

لاراول شامل یک میان افزار است که می تواند اقدامات را قبل از اینکه درخواست ورودی حتی به مسیرها یا کنترلرهای شما برسد مجوز دهد. به طور پیش‌فرض، کلید میان‌افزار در کلاس شما Illuminate\Auth\Middleware\Authorize به آن اختصاص داده می‌شود . بیایید نمونه‌ای از استفاده از میان‌افزار برای اجازه دادن به کاربر برای به‌روزرسانی یک پست وبلاگ را بررسی کنیم: can App\Http\Kernel can

use App\Post;
 
Route::put('/post/{post}', function (Post $post) {
    // The current user may update the post...
})->middleware('can:update,post');

در این مثال، ما can دو آرگومان میان افزار را ارسال می کنیم. اولی نام اقدامی است که می‌خواهیم مجوز دهیم و دومی پارامتر مسیری است که می‌خواهیم به متد Policy منتقل کنیم. در این حالت، از آنجایی که از binding مدل ضمنی استفاده می کنیم ، یک Post مدل به روش Policy منتقل می شود. اگر کاربر مجاز به انجام عمل داده شده نباشد، یک پاسخ HTTP با 403 کد وضعیت توسط میان افزار تولید می شود.

اقداماتی که به مدل نیاز ندارند

باز هم، برخی از اقدامات مانند create ممکن است نیازی به یک نمونه مدل نداشته باشند. در این مواقع، ممکن است نام کلاس را به میان افزار منتقل کنید. از نام کلاس برای تعیین اینکه از کدام خط مشی هنگام مجوز دادن به عملکرد استفاده شود استفاده می شود:

Route::post('/post', function () {
    // The current user may create posts...
})->middleware('can:create,App\Post');

از طریق Controller Helpers

User لاراول علاوه بر روش‌های مفیدی که برای مدل ارائه می‌شود ، یک authorize روش مفید برای هر یک از کنترل‌کننده‌های شما ارائه می‌کند که App\Http\Controllers\Controller کلاس پایه را گسترش می‌دهد. مانند can متد، این روش نیز نام اقدامی را که می‌خواهید مجاز کنید و مدل مربوطه را می‌پذیرد. اگر عمل مجاز نباشد، authorize متد یک را پرتاب می‌کند Illuminate\Auth\Access\AuthorizationException ، که کنترل‌کننده استثنای لاراول پیش‌فرض آن را به یک پاسخ HTTP با 403 کد وضعیت تبدیل می‌کند:

<?php
 
namespace App\Http\Controllers;
 
use App\Http\Controllers\Controller;
use App\Post;
use Illuminate\Http\Request;
 
class PostController extends Controller
{
    /**
     * Update the given blog post.
     *
     * @param  Request  $request
     * @param  Post  $post
     * @return Response
     * @throws \Illuminate\Auth\Access\AuthorizationException
     */
    public function update(Request $request, Post $post)
    {
        $this->authorize('update', $post);
 
        // The current user can update the blog post...
    }
}

اقداماتی که به مدل نیاز ندارند

همانطور که قبلاً بحث شد، برخی از اقدامات مانند create ممکن است به یک نمونه مدل نیاز نداشته باشند. در این مواقع باید یک نام کلاس به authorize متد ارسال کنید. از نام کلاس برای تعیین اینکه از کدام خط مشی هنگام مجوز دادن به عملکرد استفاده شود استفاده می شود:

/**
 * Create a new blog post.
 *
 * @param  Request  $request
 * @return Response
 * @throws \Illuminate\Auth\Access\AuthorizationException
 */
public function create(Request $request)
{
    $this->authorize('create', Post::class);
 
    // The current user can create blog posts...
}

مجوز کنترل منابع

اگر از کنترل کننده های منبع استفاده می کنید ، می توانید از authorizeResource روش موجود در سازنده کنترلر استفاده کنید. این روش تعاریف میان افزار مناسب را can به روش های کنترل کننده منابع متصل می کند.

این authorizeResource متد نام کلاس مدل را به عنوان اولین آرگومان خود و نام پارامتر route / request را که حاوی ID مدل به عنوان آرگومان دوم است می پذیرد. باید اطمینان حاصل کنید که کنترل کننده منبع شما با --model پرچم ایجاد شده است تا دارای امضاهای روش مورد نیاز و نکات نوع باشد:

<?php
 
namespace App\Http\Controllers;
 
use App\Http\Controllers\Controller;
use App\Post;
use Illuminate\Http\Request;
 
class PostController extends Controller
{
    public function __construct()
    {
        $this->authorizeResource(Post::class, 'post');
    }
}

روش‌های کنترل‌کننده زیر به روش سیاست مربوطه خود نگاشت می‌شوند:

می توانید از make:policy دستور با --model گزینه ای برای تولید سریع یک کلاس سیاست برای یک مدل داده شده استفاده کنید: php artisan make:policy PostPolicy --model=Post .

از طریق قالب های Blade

هنگام نوشتن الگوهای Blade، ممکن است بخواهید بخشی از صفحه را تنها در صورتی نمایش دهید که کاربر مجاز به انجام یک عمل خاص باشد. به عنوان مثال، ممکن است بخواهید یک فرم به روز رسانی برای یک پست وبلاگ را تنها در صورتی نشان دهید که کاربر واقعا بتواند پست را به روز کند. در این شرایط، می توانید از دستورات @can و @cannot خانواده دستورات استفاده کنید:

@can('update', $post)
    <!-- The Current User Can Update The Post -->
@elsecan('create', App\Post::class)
    <!-- The Current User Can Create New Post -->
@endcan
 
@cannot('update', $post)
    <!-- The Current User Cannot Update The Post -->
@elsecannot('create', App\Post::class)
    <!-- The Current User Cannot Create A New Post -->
@endcannot

این دستورالعمل ها میانبرهای مناسبی برای نوشتن @if و @unless بیانیه ها هستند. عبارات @can و @cannot جملات بالا به ترتیب به عبارات زیر ترجمه می شوند:

@if (Auth::user()->can('update', $post))
    <!-- The Current User Can Update The Post -->
@endif
 
@unless (Auth::user()->can('update', $post))
    <!-- The Current User Cannot Update The Post -->
@endunless

همچنین می‌توانید تعیین کنید که آیا یک کاربر توانایی مجوزدهی از فهرست مشخصی از توانایی‌ها دارد یا خیر. برای انجام این کار، از @canany دستورالعمل استفاده کنید:

@canany(['update', 'view', 'delete'], $post)
    // The current user can update, view, or delete the post
@elsecanany(['create'], \App\Post::class)
    // The current user can create a post
@endcanany

اقداماتی که به مدل نیاز ندارند

مانند بسیاری از روش‌های مجوزدهی دیگر، اگر عمل به نمونه‌ای از مدل نیاز نداشته باشد، می‌توانید نام کلاس را به دستورالعمل‌ها @can و دستورالعمل‌ها ارسال کنید: @cannot

@can('create', App\Post::class)
    <!-- The Current User Can Create Posts -->
@endcan
 
@cannot('create', App\Post::class)
    <!-- The Current User Can't Create Posts -->
@endcannot

ارائه متن اضافی

هنگام مجوز دادن به اقدامات با استفاده از خط‌مشی‌ها، می‌توانید یک آرایه را به‌عنوان آرگومان دوم به توابع و کمک‌کننده‌های مختلف مجوز ارسال کنید. اولین عنصر در آرایه برای تعیین اینکه کدام خط مشی باید فراخوانی شود استفاده می شود، در حالی که بقیه عناصر آرایه به عنوان پارامتر به روش خط مشی ارسال می شوند و می توانند برای زمینه اضافی در هنگام تصمیم گیری مجوز استفاده شوند. به عنوان مثال، تعریف روش زیر را در نظر بگیرید که حاوی یک پارامتر PostPolicy اضافی است : $category

/**
 * Determine if the given post can be updated by the user.
 *
 * @param  \App\User  $user
 * @param  \App\Post  $post
 * @param  int  $category
 * @return bool
 */
public function update(User $user, Post $post, int $category)
{
    return $user->id === $post->user_id &&
           $category > 3;
}

هنگام تلاش برای تعیین اینکه آیا کاربر تأیید شده می تواند یک پست داده شده را به روز کند یا خیر، می توانیم این روش خط مشی را به این صورت فراخوانی کنیم:

/**
 * Update the given blog post.
 *
 * @param  Request  $request
 * @param  Post  $post
 * @return Response
 * @throws \Illuminate\Auth\Access\AuthorizationException
 */
public function update(Request $request, Post $post)
{
    $this->authorize('update', [$post, $request->input('category')]);
 
    // The current user can update the blog post...
}