Сегодняшний пост снова немного об очевидной вещи - проверке данных. Зачем нужна проверка, как ее использовать, пользовательские правила и зачем нужно использовать запрос формы для проверки.
Если говорить о проектах, с которыми я сталкивался на фрилансе, то очень часто получение данных от пользователя выглядело так: В чем проблема? При таком получении данных от пользователя разработчик открывает возможность проведения двух видов атак на свое приложение:
- XSS (Cross-Site Scripting — «міжсайтовий скриптинг») — досить поширена вразливість, яку можна виявити в багатьох веб-додатках. Її суть досить проста, зловмиснику вдається впровадити на сторінку JavaScript-код, який не було передбачено розробниками.
- SQL-ін'єкція (SQL-injection) - це вразливість веб-безпеки, яка дозволяє зловмиснику втручатися в запити, які додаток робить до своєї бази даних. Як правило, це дозволяє переглядати дані, які він зазвичай не може отримати. Це можуть бути інші користувачі, або будь-які інші дані, доступ до яких має сам додаток. У багатьох випадках зловмисник може змінювати або видаляти ці дані, викликаючи постійні зміни у вмісті або поведінці програми.
Так, во-первых, валидация направлена на обеспечение безопасности данных в приложении, а во-вторых, валидация гарантирует корректность данных, вводится пользователем, и помогает избежать некорректных данных в базе данных.
Существует несколько способов проверки данных в Laravel:
- Використання методу
validate
який реалізований в трейті ValidatesRequests. За замовчуванням усі контролери, які розширюють базовий контролер наслідують цей трейт. Сам методvalidate
приймає в себе об'єкт класу Illuminate\Http\Request, масив правил для валідації полів, масив з кастомними меседжами для виводу помилок, та масив з кастомними атрибутами останні два не є обов'язковими. Тому виконати валідацію даних можливо одразу в контролері, засобами самого контролела і виглядає це так:
2. Также можно использовать метод самого класса Illuminate\Http\Request, который принимает почти те же данные, что и в предыдущем примереvalidate
, за исключением объекта $request
класса .
3. Еще один способ валидации — создать валидатор вручную с помощью фасада Illuminate\Validation\Validator и его метода. Первый аргумент, передаваемый методуmake
make
, получает тестируемые данные. Второй аргумент — это правила проверки, которые должны применяться к данным.
4. На мой взгляд, этот способ является наиболее правильным с архитектурной точки зрения. Использование валидации через отдельный класс, реализующий Form Request, позволяет решить один из главных принципов SOLID – Single Responsibility Principle. В Laravel уже реализована команда для создания класса Form Request:php artisan make:
request NewValidationRequest
Эта команда создаст следующий класс в app/Http/Requests, по умолчанию класс создается двумя методами и rules
. Метод позволяет реализовать логику проверки наличия у пользователя необходимых разрешений для выполнения запроса. Если он вернется, запрос перейдет к методу authorize
authorize
rules
проверки. Если authorize
authorize
он вернетсяtrue
false
, пользователь будет перенаправлен на страницу ошибки или обработан в соответствии с указанной пользовательской логикой. Метод rules
хранит и возвращает массив правил, по которым будут проверяться входные данные. Этот класс можно расширить, реализовав методы и , которые, в свою очередь, messages
будут возвращать пользовательские сообщения для ошибок проверки и attributes
пользовательские имена для атрибуции.
Получить чистые данные в контроллере можно при использовании класса Form Request так же, как и при использовании обычного валидатора класса Request:
I не буду копировать-вставлять, а перечислить все доступные правила для валидации. В официальной документации описаны все возможные правила https://laravel.com/docs/10.x/validation#available-validation-rules, но если этих правил недостаточно, чтобы охватить все ваши поля, у Laravel есть механизм для создания собственных пользовательских правил проверки.
Этот механизм позволяет создавать собственные правила проверки, отвечающие конкретным потребностям приложения. Чтобы создать новое правило, используйте команду:php artisan make:
rule CustomValidationRule
Он создает новое правило в папке app/Rules, а сам класс реализует только 2 методаpasses
, которые должны содержать логику, по которой будет проверяться поле и message
которая сохраняет сообщение, когда данные некорректны.
Для того, чтобы использовать это правило в валидации, достаточно добавить его в массив правил:Также существует несколько способов получения и обработки ошибок, в зависимости от опции, с помощью которой проверяются данные. Если вам нужно получить ошибки при использовании класса Validator, то все ошибки можно получить, обратившись к errors
параметру :А если для валидации использовался объект класса Request, то вы можете получить ошибки из сессии:
В случае, когда нужно обработать ошибки в blade-файлах, туда вставляется глобальная переменная, которая автоматически становится доступной для всех макетов, $errors
а также является экземпляром класса MessageBag.
Или, если вам нужно отобразить конкретную ошибку, например, для одного поля используется вспомогательная директива@error