Здравствуйте, дорогие Хабровчане.

Сегодня я представляю вашему вниманию заключающую часть цикла статей о продвинутой авторизации действий с ресурсами в Laravel. Чтобы лучше понимать о чем пойдет речь в этой статье — необходимо прочесть первую и вторую части.
  На этот раз постановка задачи немного изменилась: Мы уже имеем авторизацию действий с ресурсами посредством авторизации методов соответствующих контроллеров. Задача состоит в том, чтобы авторизовать изменение/просмотр конкретных полей модели. Так же нужно реализовать возможность авторизовать редактирование/просмотр автором своих моделей.
  Данный материал рассчитан на практикующих программистов, и будет сложен для понимания начинающему разработчику.
  Для реализации данного функционала я планирую воспользоваться встроенными трейтами Laravel HasAttributes, HidesAttributes, GuardsAttributes. С помощью этих трейтов фреймворк контролирует массовое заполнение и отображение атрибутов. Возможность форсированно заполнять/читать атрибуты я планирую оставить, так как если авторизовать полностью все действия чтения/записи — с большой вероятностью мы нарушим работоспособность программы.
  Для реализации задачи нам необходимо:
  Как и в любой задачи подобного рода необходимо решить для себя — написать расширяющий трейт, или создать родительский класс, от которого унаследовать целевой класс. В каждого метода есть свои плюсы и минусы. Но для меня главное, чтобы не было избыточности логики. То-есть постараться избежать проблемы Banana Monkey Jungle, и упростить поддержку проекта для приемников. И так как защита полей от записи/чтения достаточно точечная — я реализовал трейт. Но это дело вкуса.
  Laravel предоставляет возможность воспользоваться такими свойствами:
  При этом нужно понимать приоритет использования данных полей. Когда Вы переопределяете поле $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. Вы же, как я и писал ранее, свободны использовать свои способы.
  Стоит дополнительно отметить необходимость переопределить метод 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, что необходимо для настройки массового заполнения модели.
  Данный функционал лишь немного расширяет тот который уже имеется. Для его реализации нам необходимо в целевой модели определить связь user(), а в миграции добавить поле user_id. Далее необходимо немного видоизменить политики. Мы дополним методы, которые принимают экземпляр модели. К примеру так $user->can('delete-self-'. $this->getModelClass()). Но перед тем как проверить доступность удалять свои модели, нужно узнать владельца модели. Для этого создадим в политике метод isOwner(User $user, Model $model). В сочетании этих методов мы можем определить доступность действия. Ниже я приведу только часть класса политики, чтобы не засорять статью повторениями, но при желании — полный код можно посмотреть в репозитории.
  Отмечу также, что для избежания ошибок во время исполнения стоит ввести проверку доступности метода user() или аналогичного в целевой модели.
  На этом пока все. Надеюсь, что эта статья была полезна. Мы имеем достаточно полную и гибкую систему авторизации действий. Если есть вопросы — обязательно отвечу. Ну и конечно же конструктивные замечания или предложения также приветствуются. При желании более детально реализацию данного учебного проекта можно посмотреть в репозитории.
 PHP developer