ホームページ >PHPフレームワーク >Laravel >Laravel でリクエストの検証を処理する賢い方法
Laravel でリクエストの検証を処理する賢い方法
- 藏色散人転載
- 2019-09-20 09:41:003065ブラウズ
Laravel は Web 職人向けの PHP フレームワークです。これは、強力なアプリケーションと API を構築するのに役立ちます。ご存知のとおり、Laravel ではリクエストを検証する方法がたくさんあります。リクエストの検証の処理は、アプリケーションにとって非常に重要な部分です。 Laravel には、この問題をうまく処理する優れた機能がいくつかあります。
はじめに
私たちのほとんどは、コントローラーでバリデーターを使用することに慣れています。これは、受信リクエストの検証を処理する最も一般的な方法です。
バリデーターは次のようになります。 UserController
<?php
namespace App\Http\Controllers\API\v1\Users;
use App\Http\Controllers\Controller;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Validator;
use App\Entities\Models\User;
class UserController extends Controller
{
public function store(Request $request)
{
// validate incoming request
$validator = Validator::make($request->all(), [
'email' => 'required|email|unique:users',
'name' => 'required|string|max:50',
'password' => 'required'
]);
if ($validator->fails()) {
Session::flash('error', $validator->messages()->first());
return redirect()->back()->withInput();
}
// finally store our user
}
}コントローラーでの検証
コントローラーでの受信リクエストの検証には問題ありませんが、これは最良の方法ではなく、コントローラーが乱雑に見えることになります。私の意見では、これは悪い習慣です。コントローラーはルートからの処理リクエストを 1 つだけ処理し、適切な応答を返す必要があります。
コントローラーに検証ロジックを記述すると、単一責任の原則が崩れます。要件は時間の経過とともに変化し、要件が変わるたびにクラスの責任も変化することは誰もが知っています。したがって、1 つのクラスに多くの責任があると、管理が非常に困難になります。
Laravel には、検証ロジックを含む別のリクエスト クラスであるフォーム リクエストがあります。これを作成するには、Artisan コマンドを使用できます。
php 職人の作成: Request UserStoreRequest
これにより、新しいリクエスト クラスが作成されます app\Http\Request\UserRequest
<?php
namespace App\Http\Requests;
use Illuminate\Foundation\Http\FormRequest;
class UserStoreRequest extends FormRequest
{
/**
* Determine if the user is authorized to make this request.
*
* @return bool
*/
public function authorize()
{
return true;
}
/**
* Get the validation rules that apply to the request.
*
* @return array
*/
public function rules()
{
return [
'email' => 'required|email|unique:users',
'name' => 'required|string|max:50',
'password' => 'required'
];
}
/**
* Custom message for validation
*
* @return array
*/
public function messages()
{
return [
'email.required' => 'Email is required!',
'name.required' => 'Name is required!',
'password.required' => 'Password is required!'
];
}
}Laravel フォーム リクエスト クラスには 2 つのデフォルト メソッド auth( )そしてルール()。現在のユーザーがリクエストを許可されているかどうかに関係なく、auth() メソッドで任意の認可ロジックを実行できます。 rules() メソッドでは、すべての検証ルールを記述することができます。独自の検証メッセージの配列を渡すメソッドmessages()もあります。
ここで、UserStoreRequest を使用するように UserController を変更します。リクエスト クラスのプロンプトを入力すると、コントローラー関数を呼び出す前に自動的に解析および検証が行われます。
<?php
namespace App\Http\Controllers\API\v1\Users;
use App\Http\Controllers\Controller;
use App\Http\Requests\UserStoreRequest;
class UserController extends Controller
{
public function store(UserStoreRequest $request)
{
// Will return only validated data
$validated = $request->validated();
}
}つまり、コントローラーはスリムになり、メンテナンスが容易になりました。これで、コントローラーは検証ロジックについて心配する必要がなくなります。独自の検証クラスがあり、検証を処理し、そこでコントローラーを動作させる責任が 1 つだけあります。
検証に失敗した場合、ユーザーは前の場所にリダイレクトされ、エラーが表示されます。リクエストのタイプに応じて、セッション中にエラー メッセージが点滅します。リクエストが AJAX の場合、レスポンスは 422 ステータス コードと JSON 形式のエラーとともに返されます。
Return
入力をサニタイズすることで、アプリケーションとユーザーの安全を保ちます。アプリケーションでクリーナーを使用すると、データが常に適切にフォーマットされ、一貫性が保たれます。多くの場合、愚かな書式設定エラーが原因で検証が失敗します。
ユーザーが入力した携帯電話番号は 99-9999-999999 または 99-(9999)-(999999) です。これは非常によくある間違いであり、ユーザーに同じ詳細の再入力を強制することはできません。
他の例としては、ユーザーが電子メールを Foo@Bar.COM または FOO@Bar.com として入力した場合があります。または、FOO **bAR や foo baR**
のように姓名を入力します。Sanitizer バリデーターにフィードする前に、共通形式でデータを変換およびフィルターするメソッドが含まれています。
私は多くのフィルターを含む Waavi/Sanitizer パッケージを使用しています。
Waavi / データ クリーニング
フォーム リクエスト用の抽象クラス BaseFormRequest を作成し、ここで SanitizesInput トレイトを使用しましょう。
<?php
namespace App\Http\Requests;
use Illuminate\Contracts\Validation\Validator;
use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Http\Exceptions\HttpResponseException;
use Illuminate\Http\JsonResponse;
use Waavi\Sanitizer\Laravel\SanitizesInput;
abstract class BaseFormRequest extends FormRequest
{
use ApiResponse, SanitizesInput;
/**
* For more sanitizer rule check https://github.com/Waavi/Sanitizer
*/
public function validateResolved()
{
{
$this->sanitize();
parent::validateResolved();
}
}
/**
* Get the validation rules that apply to the request.
*
* @return array
*/
abstract public function rules();
/**
* Determine if the user is authorized to make this request.
*
* @return bool
*/
abstract public function authorize();
}これで、UserStoreRequest の次の内容を記述できるようになりました。すべてのリクエスト クラスに特性を含める必要がないように、基本クラスからフォーム リクエストを拡張します。
<?php
namespace App\Http\Requests;
class UserStoreRequest extends BaseFormRequest
{
/**
* Determine if the user is authorized to make this request.
*
* @return bool
*/
public function authorize()
{
return true;
}
/**
* Get the validation rules that apply to the request.
*
* @return array
*/
public function rules()
{
return [
'email' => 'required|email|unique:users',
'name' => 'required|string|max:50',
'password' => 'required'
];
}
public function messages()
{
return [
'email.required' => 'Email is required!',
'name.required' => 'Name is required!',
'password.required' => 'Password is required!'
];
}
/**
* Filters to be applied to the input.
*
* @return array
*/
public function filters()
{
return [
'email' => 'trim|lowercase',
'name' => 'trim|capitalize|escape'
];
}
}SanitizesInputtrait は、リクエスト データをバリデーターに提供する前にフォーマットするための filters() メソッドを提供します。 filters() メソッドは、有効なフィルターの配列を返します。ここでは、ユーザーの電子メールを小文字に変換し、名前を大文字に変換したのと同じ方法でトリミングし、HTML タグをエスケープします。
利用可能なフィルターの詳細については、こちらをご覧ください。
#結論
まず、全員に個別のリクエスト クラスを作成する必要はないようです。しかし、すべての検証ロジックを同じコントローラーに配置することを想像してください。それは悪い悪夢のようなものです。コードの管理に関して言えば、他の人がそれを管理しなければならないとしたら、どれほど悪いことでしょうか? 。 ＃＃＃＃＃＃読んでくれてありがとう。 これについてあなたの意見を聞きたいです。ご質問やご提案がございましたら、以下にコメントを残してください。 ＃＃＃＃＃＃良い１日を。 Laravel 関連の技術記事の詳細については、Laravel Framework Getting Started Tutorial
列にアクセスして学習してください。以上がLaravel でリクエストの検証を処理する賢い方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。