Введение
Здравствуйте дорогие Хабровчане.
Сегодня я представляю вашему вниманию заключающую часть цикла статей о продвинутой авторизации действий с ресурсами в Laravel. Чтобы лучше понимать о чем пойдет речь этой статье — необходимо прочесть первую и вторую части.
На этот раз постановка задачи немного изменилась: Мы уже имеем авторизацию действий с ресурсами посредством авторизации методов соответствующих контроллеров. Задача состоит в том, чтобы авторизовать изменение/просмотр конкретных полей модели. Так же нужно реализовать возможность авторизовать редактирование/просмотр автором своих моделей.
Данный материал рассчитан на практикующих программистов, и будет сложен для понимания начинающему разработчику.
Часть 4. Авторизация действий с атрибутами
Теоретическая часть
Для реализации данного функционала я планирую воспользоваться встроенными трейтами Laravel HidesAttributes, HidesAttributes, GuardsAttributes. С помощью этих трейтов фреймворк контролирует массовое заполнение и отображение атрибутов. Возможность форсированно заполнять/читать атрибуты я планирую оставить, так как если авторизовать полностью все действия чтения/записи — с большой вероятностью мы нарушим работоспособность программы.
Для реализации задачи нам необходимо:
- Переопределить методы getHidden(), getVisible() для сокрытия неавторизированных полей.
- Переопределить метод isFillable() для защиты от неавторизированной записи полей.
- Определить собственный метод authUpdate() который будет возвращать массив защищенных для записи полей.
- Определить собственный метод authView() который будет возвращать массив защищенных для чтения полей.
- Переопределить метод totallyGuarded() так как в результате дополнения логики защиты данный метод может ложно срабатывать.
Как и в любой задачи подобного рода необходимо решить для себя — написать расширяющий трейт, или создать родительский клас, от которого унаследовать целевой класс. В каждого метода есть свои плюсы и минусы. Но для меня главное, чтобы не было избыточности логики. То-есть постараться избежать проблеммы Banana Monkey Jungle, и упростить поддержку проекта для приемников. И так как защита полей от записи/чтения достаточно точечная — я реализовал трейт. Но это дело вкуса.
Laravel предоставляет возможность воспользоваться такими свойствами:
- $visible
- $hidden
- $guarded
- $fillable
При этом нужно понимать приоритет использования данных полей. Когда Вы переопределяете поле $visible система считает что все остальные поля скрыты. По аналогии — когда Вы переопределяете поле $guarded система считает что все остальные поля разрешены к заполнению. Для сохранения обратной совместимости уже написанного кода проекта — эту логику нужно не изменять, а использовать.
Приступим к практике
Хорошим тоном будет определиться с системой хранения дополнительных трейтов/хелперов/сервисов в фреймворке, и в дальнейшем соблюдать свои же требования. Для трейтов я использую путь app/Extensions/Traits, потому создаю новый трейт app/Extensions/Traits/GuardedModel. Это не системный путь, и не имеет значения где именно хранить данный функционал (как к примеру было с политиками).
В трейте я определяю методы authView()(авторизовать просмотр) и authUpdate()(авторизовать редактирование), которые будут возвращать пустые массивы, и могут быть переопределены в целевой модели.
Дальше необходимо поставить себе на службу встроенные методы getVisible() и getHidden().
Но перед этим нужно определиться, как именно будет происходить сокрытие атрибутов. Я предлагаю создать собственный метод filterVisibility(), который будет запускаться перед тем, как отработает родительский(встроенный) метод фреймворка.
Метод filterVisibility() будет сначала добавлять все защищенные поля в массив $hidden с помощью встроенного механизма makeHidden(), проходиться по массиву защищенных полей, проверяя доступность каждого посредством нашего метода userCanViewAttribute($key) и формируя массив разрешенных, и в последствии разрешать авторизованные поля с помощью встроенного механизма makeVisible()
Для определения доступности редактирования воспользуемся стандартным методом isFillable($key), который перед вызовом родительского метода будет проверять необходимость авторизовать запись данного поля, и при необходимости проверять доступность нашим методом userCanUpdateAttribute($key)
Методы userCanUpdateAttribute($key) и userCanViewAttribute($key) будут выполнять проверку авторизации. В моем случае с помощью метода $user->can() библиотеки spatie/laravel-permission. Вы же, как я и писал ранее, свободны использовать свои способы.
Трейт GuardedModel
<?php namespace App\Extensions\Traits; use App\Models\User; use Illuminate\Database\Eloquent\Model; trait GuardedModel { protected function authView(): array { return []; } protected function authUpdate(): array { return []; } public function getHidden(): array { $this->filterVisibility(); return parent::getHidden(); } public function getVisible(): array { $this->filterVisibility(); return parent::getVisible(); } public function isFillable($key) { if (in_array($key, $this->authView())) { return $this->userCanUpdateAttribute($key); } return parent::isFillable($key); } private function filterVisibility(): void { $this->makeHidden($this->authView()); $authVisible = array_filter( $this->authView(), fn ($attr) => $this->userCanViewAttribute($attr) ); $this->makeVisible($authVisible); } private function userCanViewAttribute(string $key): bool { /** @var User $user */ $user = auth()->user(); $ability = !empty($user) && $user->can("view-attr-$key-" . static::class); return $ability; } private function userCanUpdateAttribute(string $key): bool { /** @var User $user */ $user = auth()->user(); $ability = !empty($user) && $user->can("update-attr-$key-" . static::class); return $ability; } public function totallyGuarded() { $guarded = ( count($this->getFillable()) === 0 && count($this->authView()) === 0 && $this->getGuarded() == ['*'] ); return $guarded; } }
Стоит дополнительно отметить необходимость переопределить метод totallyGuarded(). Данный метод ответственный за выбрасывание исключения Illuminate\Database\Eloquent\MassAssignmentException в случаи если происходит попытка заполнения поля, когда все поля защищены и не открыты для заполнения. Таким образом если все поля пользователю не доступны к заполнению — будет сгенерировано исключение там, где оно не должно быть.
Также обратите внимание на вызов метода $user->can(«update-attr-$key-». static::class), а именно на формирование названия разрешения. Оно аналогично названию разрешения на всю модель, только с добавлением приставки attr. Именно по такому принципу нужно будет формировать разрешение при начальном посеве/использовании.
Расширим модель нашим трейтом, и определим методы authView() и authUpdate(). Для примера он будет возвращать поля user и user_id. Я умышленно взял именно атрибут user_id, чтобы продемонстрировать что user и user_id представлены разными полями. И ограничивать их просмотр нужно отдельно. Также, для примера, я добавил поля $guarded, $hidden, $fillable, что необходимо для настройки массового заполнения модели.
Модель Posts
<?php namespace App\Models; use App\Extensions\Traits\GuardedModel; use Illuminate\Database\Eloquent\Model; class Post extends Model { use GuardedModel; protected $hidden = ['id']; protected $guarded = ['created_at', 'updated_at']; protected $fillable = ['title', 'description', 'user_id']; protected function authView(): array { return ['user_id', 'user']; } protected function authUpdate(): array { return ['user_id']; } public function user() { return $this->belongsTo(User::class); } }
Часть 5. Авторизация действий со своими ресурсами
Сразу к практике
Данный функционал лишь немного расширяет тот который уже имеется. Для его реализации нам необходимо в целевой модели определить связь user(), а в миграции добавить поле user_id. Далее необходимо немного видоизменить политики. Мы дополним методы, которые принимают экземпляр модели. К примеру так $user->can(‘delete-self-‘. $this->getModelClass()). Но перед тем как проверить доступность удалять свои модели, нужно узнать владельца модели. Для этого создадим в политике метод isOwner(User $user, Model $model). В сочетании этих методов мы можем определить доступность действия. Ниже я приведу только часть класса политики, чтобы не засорять статью повторениями, но при желании — полный код можно посмотреть в репозитории.
Общая политика ModelPolicy
<?php namespace App\Policies; use App\Models\User; use Illuminate\Auth\Access\HandlesAuthorization; use Illuminate\Database\Eloquent\Model; abstract class ModelPolicy { use HandlesAuthorization; abstract protected function getModelClass(): string; public function delete(User $user, Model $model) { if ($user->can('delete-' . $this->getModelClass())) { return true; } if ($user->can('delete-self-' . $this->getModelClass())) { return $this->isOwner($user, $model); } return false; } private function isOwner(User $user, Model $model): bool { if (!empty($user) && method_exists($model, 'user')) { return $user->getKey() === $model->getRelation('user')->getKey(); } return false; } }
Отмечу также, что для избежания ошибок во время исполнения стоит ввести проверку доступности метода user() или аналогичного в целевой модели.
На этом пока все. Надеюсь, что эта статья была полезна. Мы имеем достаточно полную и гибкую систему авторизации действий. Если есть вопросы — обязательно отвечу. Ну и конечно же конструктивные замечания или предложения также приветствуются. При желании более детально реализацию данного учебного проекта можно посмотреть в репозитории.
ссылка на оригинал статьи https://habr.com/ru/post/499112/
Добавить комментарий