検索

ホームページ >バックエンド開発 >PHPチュートリアル >Laravel検証の究極のガイド

Laravel検証の究極のガイド

Johnathan Smith
Johnathan Smithオリジナル
2025-03-06 00:46:13207ブラウズ

The ultimate guide to Laravel Validation

データ検証は、Webアプリケーションの重要なコンポーネントです。セキュリティの脆弱性、データの破損、およびユーザー入力を使用するときに発生する可能性のあるさまざまな問題を防ぐのに役立ちます。

この記事では、データ検証とは何か、なぜそれが非常に重要なのかを調べます。クライアント側の検証をサーバー側の検証と比較し、クライアント側の検証を依存すべきではない理由を説明します。

次に、Laravelアプリケーションで一般的に使用する便利な検証ルールを紹介します。最後に、独自の検証ルールを作成する方法を学び、それらをテストして、それらが期待どおりに機能することを確認します。

データ検証とは何ですか？

データ検証は、データを使用しようとする前にデータの有効性をチェックするプロセスです。これは、たとえば、要求に必要なフィールドが存在するかどうか、またはフィールドが特定のパターンと一致するかどうか、またはデータベースでユニークであるかなど、より複雑なチェックをチェックする簡単なアイテムです。

通常、Webアプリケーションでデータを検証する場合、データが無効な場合は、ユーザーにエラーメッセージを返す必要があります。

これは、セキュリティの脆弱性、データの破損を防ぎ、データの精度を向上させるのに役立ちます。したがって、データが有効である場合にのみ、リクエストを処理し続けます。

覚えておいてください、ユーザーからのデータを信頼することはできません（少なくとも確認する前に！）。

なぜデータ検証が重要なのですか？

データ検証が重要である理由は、以下を含む多くの理由があります。

＃セキュリティを改善

アプリケーションでデータを検証する最も重要な理由の1つは、セキュリティを改善することです。使用する前にデータを確認することにより、アプリまたはユーザーを攻撃するために悪意のある入力が使用される可能性を減らすことができます。

＃誤ったデータストレージを防止

フィールドが整数になることを期待していると想像してくださいが、ユーザーはファイルを渡します。アプリの他の場所でそのデータを使用しようとすると、これはさまざまな問題を引き起こす可能性があります。

別の例を挙げると、ユーザーが投票に投票できるWebアプリケーションを構築しているとします。投票は、

時間とAppModelsPollモデルで指定された時間の間にのみ投票できます。投票を設定するときにopens_at時間の前に誰かが誤って設定するとどうなりますか？アプリでこれをどのように処理するかによって、これはさまざまな問題を引き起こす可能性があります。 closes_at closes_atモデルに保存する前にデータを検証することにより、アプリケーションのデータ精度を改善し、誤ったデータが保存される可能性を減らすことができます。 opens_at

＃職人コマンドが正しく入力されていることを確認してください

HTTPリクエストで渡されたデータを確認できることに加えて、職人コマンドを確認することもできます。これにより、開発者は誤って無効な値を入力し、アプリケーションに問題を引き起こすことができなくなります。

クライアントの検証とサーバー検証

通常、アプリケーションでは、クライアント側の検証とサーバー側の検証という2種類の検証を使用できます。

＃クライアント検証

クライアント検証は、データをサーバーに送信する前にブラウザで実行される検証です。 JavaScriptまたはHTML属性を使用して実装できます。

たとえば、

HTMLの数字フィールドに簡単な検証を追加して、ユーザーが入力した番号が1〜10であることを確認できます。 

<input type="number" min="1" max="10" required>
この入力フィールドには4つの別々の部分があり、クライアントの検証に役立ちます。

    ：これは、入力が数字であるべきであることをブラウザに伝えます。ほとんどのブラウザでは、ユーザーが番号以外のものを入力することができなくなります。モバイルデバイスでは、通常のキーボードの代わりに数値キーボードを持ち出すこともあります。これは、ユーザーエクスペリエンスにとって非常に有益です。
  • type="number"
    • ：これは、入力された数が少なくとも1でなければならないことをブラウザに伝えます。
  • min="1"
    • ：これは、入力された数が最大10でなければならないことをブラウザに伝えます。
  • max="10"
    • ：これは、フォームを送信する前にフィールドが必要であり、記入する必要があることをブラウザに伝えます。
  • required ほとんどのブラウザでは、ユーザーが無効な値（またはまったく値なし）でフォームを送信しようとする場合、ブラウザはフォームの送信をブロックし、ユーザーにエラーメッセージまたはプロンプトを表示します。
これは、ユーザーをガイドし、アプリケーションの全体的なユーザーエクスペリエンスを改善するために非常に有益です。しかし、それはそれが考慮すべきということだけです：ガイド。アプリケーションの唯一の形式の検証として、クライアント認証のみに依存するべきではありません。

誰かがブラウザで開発者ツールを開いた場合、設定したクライアントの確認を簡単に削除してバイパスできます。

さらに、悪意のあるユーザーがアプリを攻撃しようとする場合、通常、自動化されたスクリプトを使用してリクエストをサーバーに直接送信することを覚えておくことが重要です。これは、設定したクライアントの検証がバイパスされることを意味します。

＃サーバー側の検証

サーバー側の検証は、サーバー上のアプリケーションバックエンドで実行される検証です。 Laravelアプリケーションのコンテキストでは、これは通常、コントローラーまたはフォームリクエストクラスで実行される検証です。

検証はサーバー上にあるため、ユーザーはそれを変更できません。これは、サーバーに送信されたデータが有効であることを実際に確認する唯一の方法です。

したがって、アプリでサーバー側の検証を常に有効にすることを常に有効にしてください。理想的には、リクエストから読み取ろうとする各フィールドは、ビジネスロジックを実行するために使用しようとする前に検証する必要があります。

Laravelが確認をどのように処理するか

これで、検証とは何か、なぜそれが重要なのかを理解したので、Laravelでそれを使用する方法を見てみましょう。

しばらくLaravelを使用している場合、Laravelにはフレームワークに組み込まれた驚くべき検証システムがあることがわかります。したがって、アプリの検証を開始するのは非常に簡単です。

Laravelでデータを検証する一般的な方法はいくつかありますが、最も一般的な方法の2つをカバーします。
  • データの手動検証
    • フォームリクエストクラスを使用してデータを確認します
＃データの手動検証

データを手動で検証するには（コントローラーメソッドなど）、

ファサードを使用してIlluminateSupportFacadesValidatorメソッドを呼び出すことができます。 make

次に、2つのパラメーターを

メソッドに渡すことができます。 make

    - 検証したいデータ
  • data
    • -
  • に基づいてデータを検証したいルール rules
サイドノート：メソッドは、2つのオプションのパラメーターも受け入れます：とmake。これらを使用して、ユーザーに返されるエラーメッセージをカスタマイズできますが、この記事では説明しません。 messagesattributes 2つのフィールドを検証する可能性のある例を見てみましょう。 上記の例では、2つのフィールドを検証していることがわかります：

と

。これらの2つのフィールドの値をハードコードして、例をより明確にしますが、実際のプロジェクトでは、通常、これらのフィールドをリクエストから取得します。 
<input type="number" min="1" max="10" required>
フィールドが設定されており、文字列であり、最大100文字の長さがあるかどうかを確認しています。また、

フィールドが設定されており、文字列であり、最大250文字の長さがあるかどうかを確認します。 title body検証装置を作成した後、返されたtitleインスタンスのメソッドを呼び出すことができます。たとえば、検証が失敗したかどうかを確認するには、メソッドを呼び出すことができます：description

同様に、Validatorインスタンスで

メソッドを呼び出すこともできます：IlluminateValidationValidator fails

検証が失敗した場合、この
use Illuminate\Support\Facades\Validator;

$validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);
メソッドは

を上げます。 Laravelは、作成された要求のタイプに基づいてこの例外を自動的に処理します（アプリのデフォルトの例外処理を変更しなかったと仮定します）。リクエストがWebリクエストの場合、Laravelはセッションでエラーを使用して、ユーザーを前のページにリダイレクトして表示します。リクエストがAPIリクエストの場合、Laravelは次のように検証エラーのJSON表現を含むAvalidate応答を返します。 

$validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);

if ($validator->fails()) {
    // 一个或多个字段验证失败。
    // 在此处进行处理...
}
＃フォームリクエストクラスを使用して、データを確認します

validateLaravelアプリケーションでデータを検証するもう1つの一般的な方法は、フォームリクエストクラスを使用することです。フォームリクエストクラスは、拡張機能IlluminateValidationValidationExceptionを備えたクラスです。これは、承認チェックと着信リクエストの検証を実行するために使用されます。 422 Unprocessable Entity Laravelは、コントローラーメソッドのコードを実行する前にリクエストで渡されたデータの検証を自動的に実行するため、コントローラーメソッドを整頓するための優れた方法であると思います。したがって、Validatorインスタンスで自分自身でメソッドを実行することを忘れないでください。 

Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
)->validate();
簡単な例を見てみましょう。新しいユーザーを作成できるようにする

メソッドを備えた基本的な

コントローラーがあるとします。
<input type="number" min="1" max="10" required>

コントローラーメソッドでは、メソッドパラメーターとしてAppHttpRequestsUsersStoreUserRequestフォームリクエストクラス（後で導入します）を受け入れることがわかります。これは、Laravelに、このメソッドがHTTPリクエストを介して呼び出されたときに、このリクエストクラスで確認を自動的に実行することを示します。

次に、コントローラーメソッドのリクエストインスタンスのvalidatedメソッドを使用して、リクエストから確認されたデータを取得します。これは、検証済みのデータのみを返すことを意味します。たとえば、コントローラー内の新しいprofile_pictureフィールドを保存しようとする場合は、フォームリクエストクラスにも追加する必要があります。それ以外の場合は、validatedメソッドはそれを返さないので、$request->validated('profile_picture')はnullを返します。

AppHttpRequestsUsersStoreUserRequestフォームリクエストクラスを見てみましょう：

use Illuminate\Support\Facades\Validator;

$validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);

リクエストクラスには2つの方法が含まれていることがわかります。

  • ：この方法は、ユーザーがリクエストを行う権利を持っているかどうかを判断するために使用されます。メソッドがauthorizeを返す場合、a false応答がユーザーに返されます。メソッドが403 Forbiddenを返す場合、検証ルールが実行されます。 true
  • ：このメソッドは、リクエストに応じて実行する必要がある検証ルールを定義するために使用されます。この方法では、リクエストに応じて実行する必要があるルールの配列を返す必要があります。 rules
メソッドでは、フィールドを設定する必要があり、文字列でなければならないことを指定し、最大長は100文字でなければなりません。また、

フィールドを設定し、電子メールでなければならないことを指定し、rulesテーブル（name列）で一意でなければなりません。最後に、email usersご覧のとおり、これは検証ロジックをコントローラーロジックから分離する素晴らしい方法であり、コードの読みやメンテナンスが容易になることがわかりました。 email password一般的に使用される検証ルールは、laravel

で使用されます

私がすでに述べたように、Laravel検証システムは非常に強力であり、アプリに検証を簡単に追加できます。

このセクションでは、私が好きないくつかの便利な検証ルールをすばやく紹介します。これは、ほとんどのユーザーがアプリで役立つと思うと思います。

Laravelで利用可能なすべてのルールを表示することに興味がある場合は、Laravelのドキュメントでそれらを見つけることができます：
https://www.php.cn/link/45d5c43856059a4f97d43d6534be52d0 ＃arrayを確認します

実行する必要がある一般的なタイプの検証は、検証配列です。これは、渡されたIDアレイがすべて有効かどうかの確認から、検証リクエストで渡されたオブジェクト配列に特定のフィールドがあるかどうかを確認することになります。

配列の検証方法の例を見てみましょう。次に、実行中のことについて説明します。

<input type="number" min="1" max="10" required>
上記の例では、それぞれのフィールドを持つオブジェクトの配列を渡しています。

name検証のために、最初にemailフィールドが設定され、配列であることを定義します。次に、アレイの各アイテム（

方向を使用）は、

およびusersフィールドを含む配列であることを指定します。 users.* name次に、emailフィールド（

方向を使用）を設定する必要があり、文字列でなければならず、100文字を超えることはできないことを指定します。また、

フィールド（name方向を使用）を設定し、電子メールでなければならないことを指定し、テーブルのusers.*.name列で一意でなければなりません。 email users.*.email検証ルールでusersワイルドカードを使用できるようにすることにより、アプリケーションのデータ配列を簡単に確認できます。 email

＃検証日

*Laravelは、使用できる便利な日付検証ルールを提供します。まず、フィールドが有効な日付であることを確認するには、

ルールを使用できます。

日付が特定の形式であるかどうかを確認する場合は、

ルールを使用できます。 date

日付が別の日付よりも早いか遅いかを確認する必要があるかもしれません。たとえば、リクエストに
use Illuminate\Support\Facades\Validator;

$validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);
および

フィールドが含まれていると仮定し、date_formatが今日より遅れているか

であることを確認する必要があります。 
$validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);

if ($validator->fails()) {
    // 一个或多个字段验证失败。
    // 在此处进行处理...
}
ルール：

を使用できます opens_at 上記の例では、closes_atフィールドのルールのパラメーターとしてcloses_atを渡したことがわかります。 Laravelは、この文字列をopens_at関数を使用して有効なopens_atオブジェクトに変換し、そのオブジェクトと比較しようとします。 after 

Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
)->validate();
フィールドの場合、パラメーターとして

ルールに合格します。 Laravelは、これが検証されている別のフィールドであることを自動的に検出し、2つのフィールドを互いに比較します。 today 同様に、laravelは、日付が別の日付よりも早いかどうかを確認するために使用できるopens_atおよびafterルールも提供します。 strtotime DateTime＃パスワードを確認

Web開発者として、私たちの仕事は、ユーザーがオンラインで安全に役立つことです。これを行う方法の1つは、パスワードを特定の長さであること、特定の文字を含めるなど、アプリケーションで適切なパスワードプラクティスを宣伝することです。 closes_at opens_atLaravelは、パスワードを確認するために使用できるクラスを提供することにより、作業を簡素化します。 after_or_equal

互いにリンクして、必要なパスワード検証ルールを作成できる方法が付属しています。たとえば、ユーザーのパスワードに次の基準を満たしてほしいと仮定します。
  • 少なくとも8文字の長さ
  • には、少なくとも1つの文字
    • が含まれています
  • 少なくとも1つの大文字と1つの小文字
    • が含まれています
  • には少なくとも1つの数値が含まれています
  • には、少なくとも1つのシンボル
    • が含まれています
  • リークされたパスワードではありません（つまり、他のシステムデータ侵害でリークされたパスワードレコードを含むpwnedデータベースにはありません）

私たちの検証は次のようになるかもしれません：

<input type="number" min="1" max="10" required>

例に示すように、リンク可能な方法を使用して、必要なパスワード検証ルールを作成しています。しかし、これらのルールを複数の異なる場所（例：登録、リセット、アカウントページのパスワードを更新するなど）で使用し、少なくとも12文字を実施するためにこの検証を変更するとどうなりますか？これらのルールが使用されているすべてのものを反復し、それらを更新する必要があります。

これを簡素化するために、Laravelを使用すると、アプリケーション全体で使用できるパスワード検証ルールのデフォルトセットを定義できます。このような

メソッドを使用して、一連のデフォルトルールを定義できます。 AppProvidersAppServiceProvider これを行うと、検証ルールでbootを呼び出して、Password::defaults()で指定したルールを使用できます。 

use Illuminate\Support\Facades\Validator;

$validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);
＃色を確認します

Password::defaults()私が取り組んだほぼすべてのプロジェクトには、何らかの形のカラーピッカーが含まれています。プロフィールの色を選択するユーザー、ページの一部の背景色、またはその他のコンテンツであろうと、それは一般的なコンテンツです。 AppServiceProvider

過去には、色が16進形式の有効な色であることを確認するために、正規表現を使用しなければなりませんでした（私はそれについてあまり知らないことを認めます）。ただし、Laravelには、使用する便利な
$validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);

if ($validator->fails()) {
    // 一个或多个字段验证失败。
    // 在此处进行处理...
}
があります。

＃検証ファイル

サーバーを介してファイルをアプリにアップロードする場合、保存しようとする前にファイルが有効であることを確認する必要があります。ご想像のとおり、Laravelは使用できるファイル検証ルールを提供します。

#FF00FFユーザーがPDF（.pdf）またはMicrosoft Word（.docx）ファイルをアップロードできるようにしたいとします。検証は次のようになる場合があります：hex_color 

Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
)->validate();
コードの例では、ファイルタイプを確認していることがわかり、最小および最大ファイルサイズの制限も設定しています。

メソッドを使用して、許可するファイルタイプを指定します。

およびメソッドは、ファイルサイズユニットを示す他の接尾辞を含む文字列を受け入れることもできます。たとえば、：を使用することもできます 
{
  "message": "The title field is required. (and 1 more error)",
  "errors": {
    "title": [
      "The title field is required."
    ],
    "description": [
      "The description field is required."
    ]
  }
}

types

minmax

  • 10kb
  • 10mb さらに、
    • クラスの
  • メソッドを使用して、ファイルが画像であることを確認することもできます。
    <input type="number" min="1" max="10" required>
    上記の例では、ファイルが画像であることを確認し、最小および最大ファイルサイズの制限を設定し、最大サイズ（500 x 500ピクセル）を設定しています。

    アプリをファイルするために別のアプローチをとることをお勧めします。たとえば、ユーザーのブラウザからクラウドストレージ（S3など）に直接アップロードすることをお勧めします。これを希望する場合は、Filepondを使用してLaravelの記事で私のアップロードファイルをチェックしてください。

    ＃データベースにフィールドが存在することを確認します

    あなたがしたいと思うかもしれない別の一般的なチェックは、データベースに値が存在することを確認することです。

    たとえば、

    アプリにユーザーがいると、ルートを作成してチームに割り当てることができるとします。したがって、リクエストでは、リクエストに渡された

    がuser_idsテーブルに存在することを確認する必要がある場合があります。 users これを行うには、

    ルールを使用して、値が存在するかどうかを確認するテーブル名を渡すことができます。

    上記の例では、existsアレイで渡された各IDが

    テーブルの
    use Illuminate\Support\Facades\Validator;

$validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);
    列に存在するかどうかを確認しています。

    user_idsこれは、使用しているデータが有効であり、使用しようとする前にデータベースに存在することを確認するための優れた方法です。 users idさらに一歩進めたい場合は、

    句を

    ルールに適用して、実行中のクエリをさらにフィルタリングできます。

    上記の例では、

    配列で渡された各IDがwhereテーブルのexists列に存在するかどうかを確認しており、ユーザーの

    列が
    $validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);

if ($validator->fails()) {
    // 一个或多个字段验证失败。
    // 在此处进行处理...
}
    に設定されているかどうかを確認しています。したがって、未検証のユーザーIDに合格すると、検証が失敗します。

    user_ids＃データベースのフィールドの一意性を確認しますusers ルールと同様に、Laravelは、データベース内の値が一意であるかどうかを確認するために使用できるルールも提供します。 id たとえば、is_verifiedテーブルがあるとし、trueフィールドが一意であることを確認したいとします。

    ルール：

    を使用できます

    上記の例では、

    フィールドが設定されており、電子メールであり、existsテーブルのunique列で一意かどうかを確認しています。

    しかし、ユーザーがメールアドレスを更新できるプロフィールページでこの検証を使用しようとするとどうなりますか？ユーザーが更新しようとした電子メールアドレスを含むusersテーブルに行があるため、検証は失敗します。この場合、一意性をチェックするときにユーザーIDを無視するためにemailメソッドを使用できます。 unique 

    Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
)->validate();
    メソッドを使用することを選択した場合は、Laravelのドキュメントでこの警告を必ず読んでください。

    "ユーザー制御の要求入力をignoreメソッドに渡さないでください。代わりに、雄弁なモデルのインスタンスから自己侵入IDやUUIDなど、システムによって生成された一意のIDのみを渡す必要があります。 また、は、ルールに追加の

    条項を追加したい場合があります。これを行うには、電子メールアドレスが特定のチームに固有のものであることを確認する必要がある場合があります（これは、別のチームの別のユーザーが同じメールを使用できることを意味します）。閉鎖を

    メソッドに渡すことでこれを行うことができます：unique where where独自の検証ルールを作成します

    <input type="number" min="1" max="10" required>

    Laravelには多くの組み込みの検証ルールが付属していますが、特定のユースケースに合わせてカスタム検証ルールを作成する必要がある場合があります。

    良さに感謝します、これはLaravelでも簡単です！

    カスタム検証ルールを構築する方法、使用方法、テストを作成する方法を見てみましょう。

    この記事の目的のために、私たちは何を検証しているかについてあまり心配していません。カスタム検証ルールを作成する一般的な構造とそれらをテストする方法を理解したいだけです。したがって、文字列がパリンドロームかどうかを確認するための簡単なルールを作成します。

    わからない場合、パリンドロームは、順方向と逆方向に同じことを読む単語、フレーズ、数字、または他の文字のシーケンスです。たとえば、「レースカー」はパリンドロームです。なぜなら、弦を反転させると、まだ「レースカー」だからです。そして、「Laravel」はパリンドロームではありません。なぜなら、弦を反転させると「レバラル」になるからです。

    開始するには、プロジェクトルートで次のコマンドを実行することにより、まず新しい検証ルールを作成します。

    これは、私たちのために新しい

    ファイルを作成する必要があります：

    use Illuminate\Support\Facades\Validator;

$validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);
    Laravelは、ルールを実行するときに自動的に

    メソッドを呼び出します。このメソッドは、3つのパラメーターを受け入れます App/Rules/Palindrome.php 

    $validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);

if ($validator->fails()) {
    // 一个或多个字段验证失败。
    // 在此处进行处理...
}
    ：検証されているプロパティの名前。

    validate

    ：検証されているプロパティの値。
    • $attribute：検証が失敗した場合に呼び出すことができる閉鎖。
    • したがって、$valueは、次のように検証ロジックを
      • メソッドに追加できます。
    • 上記のルールでは、ルールに渡された値が逆転する値と同じかどうかを確認するだけです。そうでない場合は、エラーメッセージを使用して$fail閉鎖を呼び出します。これにより、フィールドが検証に失敗します。検証が通過した場合、ルールは何も実行せず、アプリケーションを使用し続けることができます。
    ルールを作成したので、このようなアプリで使用できます。

    validateこれは、デモンストレーションのために作成した単純なルールですが、アプリケーションのためにより複雑なルールを構築する方法のアイデアが得られることを願っています。

    独自の検証ルールをテストします

    アプリの他のコードと同様に、検証ルールをテストして、予想どおりに機能することを確認することが重要です。それ以外の場合は、期待どおりに機能しないルールを使用するリスクがあります。

    これを行う方法を理解するには、前のセクションで作成したパリンドロームルールをテストする方法を見てみましょう。

    この特定のルールでは、2つの状況をテストしたいと思います。

      値がパリンドロームの場合、ルールは通過します。
      • 値がパリンドロームではない場合、ルールは失敗します。
    より複雑なルールではより多くの状況があるかもしれませんが、この記事の目的のために、私たちはそれを簡単に保ちます。

    ディレクトリにtests/Unit/Rulesという名前の新しいテストファイルを作成します。 PalindromeTest.php

    テストファイルを見てみましょう。次に、実行中のことについて説明します。

    上記のテストファイルでは、2つのテストを定義します。 

    <input type="number" min="1" max="10" required>
    テスト名が示すように、最初のテストは、値がパリンドロームのときにルールが通過することを保証し、2番目のテストは、値がパリンドロームではないときにルールが故障することを保証します。

    rule_passes_with_a_valid_valuerule_fails_with_an_invalid_value属性を使用して、テストのテストに有効な値と無効な値のリストを提供します。これは、テストをきれいに保ち、同じテストで複数の値をチェックできるようにするための素晴らしい方法です。たとえば、誰かが

    メソッドに新しい有効な値を追加した場合、テストはその値に対して自動的に実行されます。

    テストでは、有効な値を使用して、ルール上のPHPUnitFrameworkAttributesDataProviderメソッドを呼び出します。クロージャーをパラメーターに渡します（このパラメーターは、ルールの内部検証が失敗した場合に呼び出されます）。閉鎖が実行された場合（つまり、検証が失敗した）、テストが失敗するはずであることを指定しました。閉鎖を実行せずにテストの終了に到達した場合、ルールが合格し、テストに合格する簡単なアサーションvalidValuesを追加できることがわかります。

    rule_passes_with_a_valid_valueテストでは、最初のテストと同じですが、今回は無効な値をルールに渡します。閉鎖が実行された場合（つまり、検証が失敗した）、閉鎖が呼び出されると予想されるため、テストが渡されることを指定しました。閉鎖を実行せずにテストの終了に到達した場合、アサーションは実行されず、Phpunitは私たちの警告をトリガーするはずです。ただし、テストがエラーを与えるよりも明示的に失敗することを確認する場合は、テストを作成するために少し異なるアプローチを取る必要がある場合があります。 validate fail結論assertTrue(true)

    この記事では、検証とは何か、なぜそれが重要であるかを調べます。クライアント側の検証をサーバー側の検証と比較し、アプリケーションの検証の唯一の形式としてクライアント側の検証を使用しない理由を調査しました。

    また、Laravelアプリで使用したい便利な検証ルールも取り上げました。最後に、独自の検証ルールを作成する方法を検討し、それらをテストして、それらが期待どおりに機能することを確認します。

    これで、アプリケーションのセキュリティと信頼性を向上させるために、より多くの検証を使用し始めるのに十分な自信を持つ必要があることを願っています。

以上がLaravel検証の究極のガイドの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

php JavaScript laravel sql json 正则表达式 html NULL date 字符串 Attribute 值传递 闭包 number 对象 选择器 数据库 http https microsoft 自动化 word Foundation
声明：
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
前の記事：Laravel View Search Pathsの管理次の記事：Laravel View Search Pathsの管理

関連記事

続きを見る