Где лучше запускать фильтрацию переданного текста комментария, для последующего сохранения?

Question

[Алексей Скляров]

Задача: реализовать возможность для некоторых групп пользователей оставлять ссылки в комментариях, для остальных - удалять ссылки.

Данные от пользователя попадают в контроллер,

public function store(StoreReviewRequest $request) {}

где они проходят валидацию, затем я получаю валидные данные: $validatedData = $request->validated();

Затем мне нужно применить фильтры к тексту отзыва/комментария, для этого я написал фильтр:

Filter

abstract class Filter
{
    protected $content;
    protected $filter;

    public function __construct($content,array $filters)
    {
        $this->content = $content;
        $this->filters = $filters;
    }

    public function apply()
    {
       // code
    }

}

TextFilter

class TextFilter extends Filter
{
    /**
     * Wrap links filter
     * 
     * @return void
     */
    public function wrapLinks()
    {
       // Code
    }
}

Написал гейт, с помощью которого я проверяю возможность пользователя оставлять ссылки в комментариях:

if(Gate::allows('useLinkInComments', $request->user()) {
  //code
}

И собственно, мне нужно в перед тем, как передать данные в модель, применить эти фильтры после проверки Gate. Делаю я это так:

new TextFilter($validatedData['message'],['wrap-links'])->apply();

Где это лучше делать? В контроллере? В таком случае (если будет расти логика) контроллер будет увеличиваться до больших размеров. Использовать хук afterValidation? Но вроде пишут что он чисто для кастомизации ошибок. Какие есть варианты правильного решения моей проблемы?

Comments

[jazzus]

Если прав нет то фильтр удаляет ссылки?

Answer 1

[Роман Сарваров]

Много способов как это сделать, но точно не в контроллере.
Я бы сделал CommentObserver:

php artisan make:observer CommentObserver --model=Comment

и там в методе saving(Comment $comment) проверял бы - есть ли право у пользователя (с помощью политики, а не гейта, кстати) и фильтровал бы как надо.

Comments

[Алексей Скляров]

Вполне интересный вариант да, забыл про обсерверы. По поводу политик, они у меня как раз и описаны, а проверяю права с помощью Gate-фасада

[Роман Сарваров]

Алексей Скляров, если мы спрашиваем разрешение на действие с моделью (в данном случае Comment), то хорошая практика использовать не Gate, а Policy классы. Если ответ помог - пометьте как решение :)

[jazzus]

Скорее всего нужна обычная превалидация

[Алексей Скляров]

jazzus, как один из вариантов, его я рассматривал тоже, но у меня прогоняется текст через пайплайн, и в целом небольшое кол-во логики присутствует (так как необходимо производить какие-то действия в зависимости от роли пользователя)

[jazzus]

Алексей Скляров, ну и что. Любые пайплайны и сервисы можно запускать в превалидации если они к этому процессу относятся. Обсервер - это обычные события модели, которые выполняются при любой работе с моделью - с тестами, фабриками скриптами и тд. Т.е. инструмент вообще не для обработки пользовательского ввода и не для проверки прав.

[jazzus]

Роман Сарваров,

хорошая практика использовать не Gate, а Policy

Gate можно использовать с политиками. А иногда только с gate например при запросах от гостя где на request user можно получить ошибку вызова метода can у null

[Роман Сарваров]

jazzus, касаемо эксепшена, то в политике можно сделать ?User и тогда, если гость, придет - передастся null. Gate можно использовать с политиками, но зачем? Политики - супер удобная штука.
Касаемо реализации этой логики в реквест файле - я считаю так делать плохо, хотя ларавель это позволяет.
Получается небольшое нарушение принципа SRP и могут в будущем быть непредвиденные проблемы из-за неочевидности (допустим он захочет сохранять в лог в контроллере оригинальный не измененый коментарий с html, а в реквесте уже придет отфильтрованный). Лучше в реквест файле провалидировать, а дальше в каком-то месте уже отредактировать комментарий для сохранения в БД как хочется.
Но в целом можно делать как душе удобно, способов много и разница не сильно большая.

[Роман Сарваров]

jazzus,

Т.е. инструмент вообще не для обработки пользовательского ввода и не для проверки прав.

Как раз таки, как мне кажется, Observer хорошо использовать, чтобы обрабатывать данные перед непосредственным сохранением в БД.

[jazzus]

Роман Сарваров, это не валидация, а обработка ввода юзера, что и нужно автору. И делается это в методе, который специально для этого в Ларавел существует.
в политике можно сделать ?User
как ты будешь вызывать это правило в логике?

[Роман Сарваров]

jazzus, Laravel это очень удобная штука, но и сборыще костылей и антипаттернов :)
Если Тейлор делает какой-то метод, это не значит что стоит это использовать.

Касаемо второго вопроса.
https://laravel.com/docs/8.x/authorization#guest-users

[jazzus]

Роман Сарваров, значит тогда не стоит использовать Ларавел. Никаких костылей я тут не вижу. Насчет второго вопроса) Повторю свой вопрос. Как ты будешь вызывать это правило в логике?

[Роман Сарваров]

jazzus,

optional(auth()->user())->can('useLinks', $comment)

[jazzus]

Роман Сарваров, это тоже самое что и через if. Я имел ввиду без проверок
Gate::allows('useLink', $comment)

[jazzus]

Роман Сарваров, к тому же если у тебя есть проверка для гостя (например enable в конфиге) то она не выполнится т.к. правило не запустится. А если проверки для гостя нет то и ?User смысла юзать нет т.к. optional вернет null. И проверка аутентификации это часть проверки авторизации, которая должна выполняться в политиках, а не в логике. Поэтому только Gate.