Laravel-ის ავტორიზაციის სისტემა კონტროლირებს რა შეუძლია დაკავშირებულ მომხმარებელს გააკეთოს (განსხვავდება ავთენტიკაციისგან — ვინ არიან ისინი). კარიბჩეები მარტივი closures-ები არიან ნებართვებისთვის; პოლიტიკები კლასები არიან, რომლებიც ორგანიზებენ ავტორიზაციის ლოგიკას კონკრეტული მოდელის გარშემო (მაგ. ვინ შეუძლია Post-ის განახლება).
::(, fn() => ->());
(::()) { ... }
::();
კარიბჩეები კარგია მარტივი, ცალკე ნებართვებისთვის, რომლებიც კონკრეტულ მოდელთან არ არიან დაკავშირებული.
<?php
// php artisan make:policy PostPolicy --model=Post
class PostPolicy {
public function update(User $user, Post $post): bool {
return $user->id === $post->user_id; // only the author can update
}
public function delete(User $user, Post $post): bool {
return $user->id === $post->user_id || $user->isAdmin();
}
}
პოლიტიკის კლასი აჯგროვებს მოდელის ავტორიზაციის წესებს — თითოეული მეთოდი პასუხობს "შეუძლია თუ არა ამ მომხმარებელს ამ მოდელზე ეს მოქმედება გაკეთოს?". ეს ავტორიზაციის ლოგიკას ორგანიზებული რჩება რესურსის მიხედვით.
// in a controller
public function update(Request $request, Post $post) {
$this->authorize('update', $post); // checks PostPolicy::update — throws 403 if denied
// ... proceed (we know the user is authorized)
}
// the user model
if ($request->user()->can('update', $post)) { ... }
{{-- in Blade — show UI only if authorized --}}
@can('update', $post)
<a href="{{ route('posts.edit', $post) }}">Edit</a>
@endcan
მეთოდები authorize()/can() (და @can Blade-ში) ავტომატურად აკონტროლებენ პოლიტიკას — 403 გამონაკლის დაკიდება ან UI დამალვა, როდესაც მომხმარებელი არ არის ნებართვილი.
ავტორიზაცია აუცილებელი და უსაფრთხოების კრიტიკული — კონტროლირება რა შეუძლია დაკავშირებულ მომხმარებელს გააკეთოს (არა მხოლოდ ჩაწერილია თუ არა) აპლიკაციის უსაფრთხოების საფუძველი, და Laravel-ის პოლიტიკები და კარიბჩეები აძლევს깨끗한, ორგანიზებულ მეთოდს მისი მართვის.
ავთენტიკაციის (ვინ ხარ — ლოგინი) და ავტორიზაციის (რა შეუძლია გააკეთო — ნებართვები) მიმართ განსხვავების გაცნობიერება საფუძველი, და ავტორიზაციის უარყოფა იწვევს სერიოზულ დაუცველობას (მომხმარებლები მიივლენ ან ცვლიან მონაცემებს, რომელთა კეთება არ უნდათ — broken access control ყველაზე საშიში უსაფრთხოების რისკია).
Laravel-ის სისტემა აძლევს ორ კომპლემენტარულ ინსტრუმენტს: კარიბჩეებს მარტივი, ცალკე ნებართვებისთვის (closure-ზე დაფუძნებული შემოწმებები), და პოლიტიკებს — გავრცელებული, რეკომენდირებული მეთოდი — რომლებიც აჯგროვებენ მოდელის ავტორიზაციის წესებს 専用ი კლასში (მაგ. ვინ შეუძლია Post-ის განახლება ან წაშლა), რაც ავტორიზაციის ლოგიკას სტრუქტურირებული და გაბ maintenance-ელი ხდის რესურსის მიხედვით.
გაცნობიერება თუ როგორ განსაზღვროთ პოლიტიკები/კარიბჩეები და ამოიდენტიფიეროთ ისინი ($this->authorize(), $user->can(), @can Blade-ში — ნებართვების შემოწმება კონტროლერებში, 403-ის დაკიდება, და UI-ს პირობობრივი ჩვენება) მნიშვნელოვანია უსაფრთხო აპლიკაციების აგებისთვის, სადაც მომხმარებლები შეუძლიათ მხოლოდ ნებართვილი მოქმედებების განხორციელება.
ვინაიდან თითქმის ყველა რეალური აპლიკაცია საჭიროებს დეტალური წვდომის კონტროლი (უზრუნველყოფა, რომ მომხმარებლები შეუძლიათ მხოლოდ თავიანთი რესურსების შეცვლა, ადმინ მოქმედებების შეზღუდვა და ა.შ.), და ვინაიდან ავტორიზაციის არასწორი განხორციელება ქმნის საშიში უსაფრთხოების ხვრელებს, Laravel-ის პოლიტიკებისა და კარიბჩეების ცოდნა — ავტორიზაციის უზიარი, ორგანიზებული გზა — მნიშვნელოვანი უსაფრთხოების სამიზნე უფროსი ცოდნა, რომელიც აუცილებელია აპლიკაციების აგებისთვის, რომელიც სწორად აძლევდა უფლებას ვინ შეუძლია რა გააკეთოს, რეალური სისტემების ხშირი და კრიტიკული მოთხოვნა.