Как правильно использовать middleware в Laravel?

Question

[vlad3144]

Почему-то сложилось такое мнение, на основе просмотренных видео материалов и примеров из интернета, что middleware используют только для проверки аутентификации и авторизации пользователей.
Есть ли, например, смысл использовать middlaware для проверки валидности данных передаваемых из формы в контроллер?
Помогите, пожалуйста, разобраться.

Comments

[JhaoDa]

А если бы ты читал документацию вместо просмотра сомнительных видео, то знал бы, что в ларавел для валидации есть отдельные механизмы.

И знал бы, для чего можно использовать мидлвари.

[Модератор]

vlad3144 дорогой пользователь, настоятельно рекомендуем еще раз обратить самое пристальное внимание на п. 3.1 регламента работы сервиса (и, в особенности, на его последний абзац). В противном случае, ваши вопросы будут удаляться по причине тег-спама, а систематические нарушения приведут к блокировке учетной записи.

Answer 1

[jazzus]

Валидация полей форм
Создаешь форму.
Создаешь Реквест файл.
Прописываешь там правила и сообщения.
Подключаешь в контроллере, в метод куда идет пост-запрос и данный файл будет валидировать поля.
Middleware не валидирует поля. Используют, чтобы фильтровать запросы. Например, разрешить доступ к определенным роутам только пользователям, которые отвечают условиям. Плюс провести действия в процессе проверки. Например, заблокированных разлогинить и редирекнуть на главную.

Answer 2

[grinat]

Нет. Хз в ларавел, но если там mvc, то данные запроса обратываются в контроллере, а middlaware там будет тем что стоит перед твоей обработкой в контролере. То есть например авторизация, мы в middlaware проверяем авторизован ли пользователь, если да, то передаем данные дальше на обработку в контролер. На практике их есть смысл заюзать если например пришел аналитик и сказал что если мы обрабатываем овощ, то надо выводить человеку сообщение: ты помидор, а у тебя куча контролер: картофанконтрлер, капустаконтролер, луккнотролер и т.п., и ты вместо того чтобы в них все вставлять сообщение ты помидор, добавляешь middlaware и в нем смотришь овощ ли это, и если да, то выводишь сообщение ты помидор.

Answer 3

[javanub]

Для валидации полей, есть валидатор

public function store(Request $request, StoreBlogTag $store)
{
$validate = Validator::make($request->all(), $store->rules(), $store->messages());
if ($validate->fails()) {
return redirect('post/create')
->withErrors($validate)
->withInput();
};
$tag = Tag::firstOrCreate([
'title' => $request->input('title'),
'slug' => Str::slug($request->input('title'), '-'),
]);
$tag->save();
return redirect()->back();
}

Comments

[Николай]

Жесть

[Дмитрий]

Есть FormRequest

[javanub]

Николай, объясните?

[Николай]

Начнем с того, что вы зачем-то приводите кусок выдранного неотформатированного кода, в котором куча непонятных объектов и подходов. Это просто неуважение к сообществу. Ок, мы не тупые, разберемся.

1.

public function store(Request $request, StoreBlogTag $store)

Ну мы типа поняли, что в StoreBlogTag хранятся правила валидации и ошибки для валидации для тэгов. Зачем это все нужно из текущего кода не понять. Как уже не раз отметили, все это можно заменить на Form Request Validation.

2.

$validate = Validator::make($request->all(), $store->rules(), $store->messages());
if ($validate->fails()) {
    return redirect('post/create')
    ->withErrors($validate)
    ->withInput();
};

Зачем нам эта копипаста? Вы же вроде тэги создаете. А почему редиректите на `post/create` - как это можно понять? Что это нам вообще дает? Здесь какой-то специфический редирект? Иначе можно возложить это все на Ларавел и заменить на:

Validator::make($request->all(), $store->rules(), $store->messages())->validate();

Хотя, опять же не понять, зачем вообще делать валидацию через make?

3.

$tag = Tag::firstOrCreate([
'title' => $request->input('title'),
'slug' => Str::slug($request->input('title'), '-'),
]);

Зачем вообще в данном случае приводить такой сложный пример? Нельзя что ли простой create с mass-assignment привести? Зачем делать проверку по двум полям? Почему slug генерируется в контролере? Для slug вообще полно готовых решений в виде трэйтов.

4.
$tag->save();
Это типа, если вдруг, с первого раза не сохранилось (метод firstOrCreate создает запись в БД), еще раз сохраним для подстраховочки :)

Короче, вот пример для топикстартера (возврат ресурсов т.к. это API):

class BrandController extends Controller
{
    //    [...]
    public function store(SaveBrand $request)
    {
        $brand = Brand::create($request->all());
        return new BrandResource($brand);
    }

    public function update(SaveBrand $request, Brand $brand)
    {
        $brand->update($request->all());
        return new BrandResource($brand);
    }
}

+

class SaveBrand extends FormRequest
{
    public function authorize()
    {
        return true;
    }

    public function rules()
    {
        $rules = [
            'name' => [
                'required',
                'max:100',
                Rule::unique('brands')->ignore($this->id)
            ],
            'url' => [
                'required',
                'max:100',
                'url',
                Rule::unique('brands')->ignore($this->id)
            ]
        ];

        // Позволяет редактировать по одному полю в запросе
        if ($this->method() == 'PATCH') {
            foreach ($rules as $key => $item) {
                array_unshift($rules[$key], 'sometimes');
            }
        }

        return $rules;
    }
}

+

class BrandResource extends JsonResource
{
    public function toArray($request)
    {
        return parent::toArray($request);
    }
}

[javanub]

Николай, спасибо за ответ. Это и правда кусок, который редирект на post. Соообщение не форматировано, вставлял с телефона. Ну все равно спасибо за фидбек.

Answer 4

[Danny Chase]

Прекратите раздувать контроллеры, пусть они выполняют свои прямые функции, логику пишите в сервис классах, валидацию пишите в реквестах, посредники нэможно использовать не только для авторизации, по best practice в ларавель, их используют для работы с входящими http запросами, проверка токенов, добавление и проверки специальных заголовков, редиректы, логгирование, cors, итд итп, то есть вся логика приложения которая должна отработать до выполнения бизнес логики