• Время чтения ~0 мин
  • 08.09.2023

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

Если говорить о проектах, с которыми я сталкивался на фрилансе, то очень часто получение данных от пользователя выглядело так: В чем проблема? При таком получении данных от пользователя разработчик открывает возможность проведения двух видов атак на свое приложение:

  1. XSS (Cross-Site Scripting — «міжсайтовий скриптинг») — досить поширена вразливість, яку можна виявити в багатьох веб-додатках. Її суть досить проста, зловмиснику вдається впровадити на сторінку JavaScript-код, який не було передбачено розробниками.
  2. SQL-ін'єкція (SQL-injection) - це вразливість веб-безпеки, яка дозволяє зловмиснику втручатися в запити, які додаток робить до своєї бази даних. Як правило, це дозволяє переглядати дані, які він зазвичай не може отримати. Це можуть бути інші користувачі, або будь-які інші дані, доступ до яких має сам додаток. У багатьох випадках зловмисник може змінювати або видаляти ці дані, викликаючи постійні зміни у вмісті або поведінці програми.

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

Существует несколько способов проверки данных в Laravel:

  1. Використання методу validate який реалізований в трейті ValidatesRequests. За замовчуванням усі контролери, які розширюють базовий контролер наслідують цей трейт. Сам метод validate  приймає в себе об'єкт класу Illuminate\Http\Request, масив правил для валідації полів, масив з кастомними меседжами для виводу помилок, та масив з кастомними атрибутами останні два не є обов'язковими. Тому виконати валідацію даних можливо одразу в контролері, засобами самого контролела і виглядає це так:

2. Также можно использовать метод самого класса Illuminate\Http\Request, который принимает почти те же данные, что и в предыдущем примереvalidate, за исключением объекта $requestкласса .

3. Еще один способ валидации — создать валидатор вручную с помощью фасада Illuminate\Validation\Validator и его метода. Первый аргумент, передаваемый методуmakemake, получает тестируемые данные. Второй аргумент — это правила проверки, которые должны применяться к данным.

4. На мой взгляд, этот способ является наиболее правильным с архитектурной точки зрения. Использование валидации через отдельный класс, реализующий Form Request, позволяет решить один из главных принципов SOLIDSingle Responsibility Principle. В Laravel уже реализована команда для создания класса Form Request:php artisan make:

request NewValidationRequest

Эта команда создаст следующий класс в app/Http/Requests, по умолчанию класс создается двумя методами и rules. Метод позволяет реализовать логику проверки наличия у пользователя необходимых разрешений для выполнения запроса. Если он вернется, запрос перейдет к методу authorize authorize rules проверки. Если authorize authorize он вернетсяtruefalse, пользователь будет перенаправлен на страницу ошибки или обработан в соответствии с указанной пользовательской логикой. Метод 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

Приклад виводу однієї вибранох помилки

Comments

No comments yet
Yurij Finiv

Yurij Finiv

Full stack

Про мене

Professional Fullstack Developer with extensive experience in website and desktop application development. Proficient in a wide range of tools and technologies, including Bootstrap, Tailwind, HTML5, CSS3, PUG, JavaScript, Alpine.js, jQuery, PHP, MODX, and Node.js. Skilled in website development using Symfony, MODX, and Laravel. Experience: Contributed to the development and translation of MODX3 i...

Об авторе CrazyBoy49z
WORK EXPERIENCE
Контакты
Ukraine, Lutsk
+380979856297