Изучите ценность пользовательских правил и проверки данных (с Laravel) в Inspector
27 марта 2022 г.Фото Мэтью Шварц на Unsplash
Привет, я Валерио Барбера, инженер-программист, основатель и технический директор Inspector.
Проверка данных — одна из фундаментальных функций любого приложения, и разработчики манипулируют ею почти каждый день.
Ценность программного обеспечения для пользователей часто зависит от качества данных, которыми оно может управлять.
Laravel поставляется с множеством [предопределенных правил проверки] (https://laravel.com/docs/master/validation#available-validation-rules), которые вы можете сразу же использовать в своих контроллерах.
Работая над серверной частью Inspector, мы определили некоторые аспекты проверки входящих данных, которые влияют на безопасность и надежность приложения.
Кроме того, благодаря пользовательским правилам вы можете легко расширить уровень проверки вашего приложения с помощью функций, предоставляемых внешними службами.
Позвольте мне начать с небольшого контекста, чтобы прояснить роль уровня проверки в серверной службе, а затем я покажу вам наши реализации.
Слой проверки Laravel
Целостность и проверка данных — важные аспекты веб-разработки, поскольку они определяют состояние приложения. Если данные неверны, приложение ведет себя неправильно.
Всегда важно проверять данные не только перед их сохранением в базе данных, но и перед тем, как что-либо делать с данными.
В жизненном цикле запроса Laravel HTTP-запрос, отправленный клиентом, сначала проходит через промежуточное ПО. Промежуточное программное обеспечение имеет дело с сочетанием вещей между аутентификацией и безопасностью.
Теперь, прежде чем запрос попадет в приложение, данные, которые он содержит, должны быть проверены.
Есть два способа выполнить проверку данных в Laravel: внутри контроллеров или с помощью запросов формы.
Проверка в контроллере
Самый простой способ проверки — выполнить ее непосредственно в контроллере. В начале каждого метода контроллера вы можете сначала проверить данные:
```php
<?php
пространство имен App\Http\Controllers;
используйте Illuminate\Http\Request;
класс UserController расширяет контроллер
хранилище общедоступных функций (запрос $ request)
$запрос->проверить([
'имя' => 'обязательно|строка|минимум: 3',
'электронная почта' => 'обязательно|электронная почта|минимум: 6',
// здесь мы знаем, что данные действительны, поэтому мы можем передать их в базу данных или другие службы
Laravel позаботится о том, чтобы вернуть клиенту код ответа 422, если данные недействительны.
Использовать запросы формы
Если ваши правила проверки слишком сложны, вы можете захотеть инкапсулировать их в повторно используемые классы, чтобы избежать путаницы в контроллере.
Laravel предоставляет возможность обернуть проверку в специальный компонент под названием [FormRequest] (https://laravel.com/docs/master/validation#form-request-validation).
Сначала создайте класс запроса формы:
php artisan make:запрос StoreUserRequest
Затем переместите логику проверки в метод rules класса запроса:
```php
<?php
пространство имен App\Http\Requests;
используйте Illuminate\Foundation\Http\FormRequest;
класс StoreUserRequest расширяет FormRequest
- Определите, авторизован ли пользователь для выполнения этого запроса.
- @вернуть логическое значение
публичная функция авторизации()
вернуть истину;
- Получите правила проверки, применимые к запросу.
- @возвратный массив
правила публичной функции()
вернуть [
'имя' => 'обязательно|строка|минимум: 3',
'электронная почта' => 'обязательно|электронная почта|минимум: 6',
Вы можете указать этот новый класс запроса в методе контроллера вместо исходного класса запроса, чтобы Laravel автоматически применил правила проверки и удалил оператор проверки:
```php
<?php
пространство имен App\Http\Controllers;
используйте App\Http\Requests\StoreUserRequest;
класс UserController расширяет контроллер
хранилище общедоступных функций (StoreUserRequest $ request)
// здесь мы знаем, что данные действительны, поэтому мы можем передать их в базу данных или другие службы
Пользовательские правила проверки
Laravel предоставил действительно хорошо проработанный слой проверки. Его можно легко расширить, внедрив пользовательские правила для повторного использования в коде или расширив возможности проверки с помощью внешних служб.
Позвольте мне показать вам реальный пример одного из пользовательских правил, которые мы реализовали в Inspector.
Сначала создайте класс, представляющий правило проверки в Laravel:
php artisan make:rule SecurePassword
Идея состоит в том, чтобы проверить, находится ли пароль в списке известных небезопасных паролей. Если это так, он не пройдет проверку, вынуждая пользователя использовать менее распространенную строку.
```php
<?php
пространство имен App\Rules;
используйте Illuminate\Contracts\Validation\Rule;
класс SecurePassword реализует правило
- Определите, проходит ли правило проверки.
- @param строка $атрибут
- @param смешанное значение $
- @вернуть логическое значение
публичные функции проходят ($ атрибут, $ значение)
вернуть !in_array($значение, [
'картинка1',
'пароль',
'пароль1',
'12345678',
'111111',
- Получите сообщение об ошибке проверки.
- @возвратная строка
сообщение публичной функции()
return 'Выбранный пароль ненадежен. Попробуйте еще раз с менее распространенной строкой.';
Интеграция с внешними службами
Говоря о проверке данных, существует множество сервисов SaaS, которые могут предоставить новые возможности на вашем уровне проверки с точки зрения безопасности и надежности собранных данных.
Я рекомендую вам взглянуть на apilayer.com, который предоставляет отличный набор сервисов REST для работы с данными.
В Inspector мы используем API mailboxlayer.com для проверки электронных писем. Служба также может обнаруживать поддельные адреса электронной почты, временные адреса и фактическое существование адреса электронной почты с помощью MX-Records и SMTP.
Добавьте два свойства конфигурации для хранения ключей API новых сервисов в файле config/service.php:
```php
вернуть [
'почтовый ящик' => [
'ключ' => env('MAILBOXLAYER_KEY'),
'ватный слой' => [
'ключ' => env('VATLAYER_KEY'),
Создайте пользовательское правило:
php artisan make:rule EmailSpam
Вот полный код правила:
```php
<?php
пространство имен App\Rules;
используйте Illuminate\Contracts\Validation\Rule;
класс EmailSpam реализует правило
- Определите, проходит ли правило проверки.
- @param строка $атрибут
- @param смешанное значение $
- @вернуть логическое значение
публичные функции проходят ($ атрибут, $ значение)
если (приложение()->среда('локальный')) {
вернуть истину;
return !config('services.mailboxlayer.key') || $это->проверить($значение);
- Выполните проверку электронной почты.
- @param строка $email
- @вернуть логическое значение
проверка защищенной функции (строка $email): bool
пытаться{
$response = file_get_contents('https://apilayer.net/api/check?'.http_build_query([
'access_key' => config('services.mailboxlayer.key'),
'email' => '[mailbox-layer-account-email]',
'SMTP' => 1,
$ ответ = json_decode ($ ответ, правда);
return $response['format_valid'] && !$response['одноразовый'];
} поймать (\ Исключение $ исключение) {
отчет ($ исключение);
если (приложение()->среда('локальный')) {
вернуть ложь;
// Не блокировать производственную среду в случае ошибки апислоя
вернуть истину;
- Получите сообщение об ошибке проверки.
- @возвратная строка
сообщение публичной функции()
return 'Неверный адрес электронной почты.';
Советы и хитрости
Проверить границы
Основываясь на своем опыте, я могу предложить вам всегда проверять не только минимальный размер входящих полей, но и максимальный размер.
Не ждите ошибок базы данных, которые усекают слишком длинные строки, и помогите вашим пользователям понять ограничения каждого поля с помощью сообщений об ошибках, возвращаемых во время проверки.
Запросить текущий пароль
Каждое критическое действие должно требовать подтверждения пароля.
Вы всегда должны предлагать пользователю ввести текущий пароль, чтобы авторизовать действия, которые могут поставить под угрозу доступ к учетной записи, например изменить адрес электронной почты и изменить пароль.
Эта функция повысит безопасность, поскольку, также имея физический доступ к компьютеру с открытой на экране панелью Inspector, злоумышленник не может изменить учетные данные для доступа, не зная текущего пароля. Он не может закрыть тебя.
Вот наша реализация текущей проверки пароля:
```php
<?php
пространство имен App\Rules;
используйте Illuminate\Contracts\Validation\Rule;
используйте Illuminate\Support\Facades\Auth;
используйте Illuminate\Support\Facades\Hash;
класс CurrentPassword реализует правило
- Определите, проходит ли правило проверки.
- @param строка $атрибут
- @param смешанное значение $
- @вернуть логическое значение
публичные функции проходят ($ атрибут, $ значение)
вернуть Hash::check($value, Auth::user()->password);
- Получите сообщение об ошибке проверки.
- @возвратная строка
сообщение публичной функции()
return 'Ваш текущий пароль неверен.';
Впервые в Инспекторе?
Вы ищете «управляемый кодом» инструмент мониторинга для автоматического выявления технических проблем в ваших приложениях?
Получите среду мониторинга, специально разработанную для разработчиков программного обеспечения, избегая какой-либо конфигурации сервера или инфраструктуры.
Благодаря Inspector вам никогда не придется устанавливать что-то на уровне сервера или выполнять сложную настройку в вашей облачной инфраструктуре для мониторинга вашего приложения в режиме реального времени.
Inspector работает с облегченной библиотекой программного обеспечения, которую вы можете установить в своем приложении, как и любые другие зависимости, основанные на технологии, которую вы используете для разработки серверной части.
Ознакомьтесь с поддерживаемыми технологиями на нашем GitHub (https://github.com/spector-apm).
Посетите наш веб-сайт для получения более подробной информации: https://spector.dev/laravel/
Оригинал