LIVR-「言語に依存しない検証ルール」または「問題」のないデータ検証

各プログラマーは、ユーザー入力を検証する必要性に繰り返し直面しています。 10年以上ウェブ開発に携わってきたので、多くのライブラリを試しましたが、自分のタスクを解決するライブラリを見つけられませんでした。



データ検証ライブラリで発生する主な問題



問題番号1。 多くのバリデーターは、検証ルールが記述されているデータのみを検証します。 私にとって、明示的に許可されていないユーザー入力は無視されることが重要です。 つまり、バリデーターは、検証ルールが記述されていないすべてのデータを切り出す必要があります。 これは単に基本的な要件です。



問題番号2。 検証ルールの手順説明。 毎回検証アルゴリズムについて考えるのではなく、正しいデータがどのように見えるかを宣言的に説明したいだけです。 基本的に、データスキームを定義したい（投稿の最後に「JSONスキーマ」ではない理由）。



問題番号3。 コードの形式での検証ルールの説明。 これはそれほど怖くないように思えますが、検証ルールをシリアル化し、バックエンドとフロントエンドで同じ検証ルールを使用しようとするすべての試みを即座に無効にします。



問題番号4 。 検証はエラーで最初のフィールドで停止します。 この方法では、フォーム内のすべてのエラー/必須フィールドをすぐに強調表示することはできません。



問題番号5。 標準化されていないエラーメッセージ。 たとえば、「フィールド名が必要です。」 いくつかの理由で、ユーザーにそのようなエラーを表示できません。

• インターフェイスのフィールドは、まったく異なる方法で呼び出すことができます
• インターフェイスは英語ではない可能性があります
• エラーのタイプを区別する必要があります。 たとえば、特別な方法で空の値のエラーを表示します

つまり、エラーメッセージではなく、標準化されたエラーコードを返す必要があります。



問題番号6。 数値エラーコード。 使用するのは単に不便です。 エラーコードを直感的にしたいです。 エラーコード「REQUIRED」はコード「27」よりも理解しやすいことに同意します。 ロジックは、例外クラスの操作に似ています。



問題番号7。 階層データ構造を確認する方法はありません。 今日、さまざまなJSON APIの時代には、それなしではできません。 階層データ自体の検証に加えて、各フィールドのエラーコードを返す必要があります。



問題番号8。 限られたルールのセット。 標準ルールは常に不足しています。 バリデータは拡張可能で、複雑なルールを追加できるようにする必要があります。



問題番号9。 責任の範囲が広すぎる。 バリデーターはフォームを生成してはならず、コードを生成してはならず、検証以外は何もすべきではありません。



問題番号10。 追加のデータ処理を実行できない。 ほとんど常に、検証がある場合、追加の（多くの場合予備的な）データ処理が必要です：禁止文字を切り取り、小文字、余分なスペースを削除します。 特に重要なのは、行頭と行末のスペースの削除です。 99％のケースでは、必要ありません。 バリデーターは検証以外のことをしてはならないと前に言ったことを知っています。



3年前、上記のすべての問題を抱えていないバリデーターを作成することが決定されました。 そのため、LIVR（Language Independent Validation Rules）がありました。 Perl、PHP、JavaScript、Pythonの実装があります（私たちはpythonで書いていません-それについてのフィードバックはできません）。 バリデーターは、会社のほぼすべてのプロジェクトで数年にわたって本番環境で使用されています。 バリデータはサーバーとクライアントの両方で機能します。 バリデーターはwebbylab.github.io/livr-playgroundで試すことができます。



重要なアイデアは、バリデーターのコアは最小限であるべきであり、検証のロジック全体がルール内にあるということです（むしろ、それらの実装にあります）。 つまり、バリデーターでは、「必須」（値の存在をチェック）、「max_length」（最大長をチェック）、「to_lc」（データを小文字にする）、「list_of_objects」（フィールドのルールを説明するのに役立ちます）の間に違いはありませんオブジェクトの配列）。



言い換えれば、バリデーターは何も知りません：

• エラーコードについて
• 階層オブジェクトを検証する方法を知っていること
• 彼がデータを変換/消去できること
• 他の多くのことについて

これはすべて検証規則の責任です。



LIVR仕様



タスクは、バリデータをプログラミング言語、つまり口ひげ/ハンドルバーから独立させることでしたが、データ検証の世界でのみ、仕様を書くことから始めました。



仕様の目的：

1. データ記述形式を標準化します。
2. 各実装でサポートする必要がある検証ルールの最小セットを説明します。
3. エラーコードを標準化します。
4. すべての実装のための単一の基本文書である。
5. 実装が仕様に準拠しているかどうかを確認できる一連のテストデータを用意します。

仕様はlivr-spec.orgで入手できます。



主なアイデアは、検証ルールの説明はデータスキームのように見え、ルール値ではなくデータにできるだけ類似していることです。



承認フォームの検証規則の説明の例（ デモ ）：

{ email: ['required', 'email'], password: 'required' }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

登録フォームの検証規則の例（ demo ）：

 { name: 'required', email: ['required', 'email'], gender: { one_of: ['male', 'female'] }, phone: {max_length: 10}, password: ['required', {min_length: 10} ] password2: { equal_to_field: 'password' } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ネストされたオブジェクトの検証の例（ demo ）：

 { name: 'required', phone: {max_length: 10}, address: { 'nested_object': { city: 'required', zip: ['required', 'positive_integer'] }} }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

検証ルール



検証ルールはどのように記述されますか？ 各ルールは名前と引数で構成され（ほぼ関数呼び出しのように）、一般的に次のように記述されます{"RULE_NAME"：ARRAY_OF_ARGUMENTS}。 各フィールドには、順番に適用されるルールの配列が記述されています。



例えば

 { "login": [ { length_between: [ 5, 10 ] } ] }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、「ログイン」フィールドと、2つの引数（「5」と「10」）を持つ「length_between」ルールがあります。 これは最も完全な形式ですが、次の単純化が許可されています

• フィールドに1つのルールがある場合、配列はオプションです
• ルールに引数が1つある場合、それを渡すことができます（配列にフレーミングすることなく）
• ルールに引数がない場合は、ルールの名前を単に書くことができます。

3つのエントリはすべて同一です。

 "login": [ { required: [] } ]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 "login": [ "required" ]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 "login": "required"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

詳細については、仕様の「仕組み」セクションを参照してください。



サポートされているルール



すべてのルールは、3つのグローバルグループに分けることができます。

• データ（数値、文字列など）を検証するルール。 たとえば、「max_length」。
• より単純なルールでより複雑なルールを作成できるルール。 たとえば、「nested_object」。
• データを変換するルール。 たとえば、「to_lc」

しかし、バリデーター自体はそれらを区別しません、彼にとってそれらはすべて等しいです。



以下に、各バリデーター実装でサポートする必要があるルールの一般的なリストを示します。



基本的なルール

• 必須-フィールドは必須であり、値は空であってはなりません
• not_empty-フィールドはオプションですが、空の場合は空にできません
• not_empty_list-値には空でない配列が含まれている必要があります

文字列をチェックするためのルール

• one_of
• max_length
• min_length
• length_between
• length_equal
• のような

番号をチェックするためのルール

• 整数
• positive_integer
• 小数
• positive_decimal
• max_number
• min_number
• number_between

特別な形式のルール

• メール
• url
• iso_date
• equal_to_field

より複雑なルールを記述するためのルール（メタルール）

• nested_object-ネストされたオブジェクトのルールを説明します
• list_of-リストの各要素が従わなければならない規則を記述します
• list_of_objects-値は目的の形式のオブジェクトの配列である必要があります
• list_of_different_objects-異なるタイプのオブジェクトの配列を確認する必要がある場合に使用します。

データ変換の規則（名前は動詞で始まります）

• trim-末尾の先頭のスペースを削除します
• to_lc-小文字になります
• to_uc-大文字になります
• remove-指定された文字を削除します
• leave_only-指定された文字のみを残す

メタルール



各ルールの例とエラーコードは、LIVR仕様に記載されています。 メタルールについてのみもう少し詳しく説明します。 メタルールは、複雑な階層データ構造を検証するために、単純なルールをより複雑なルールに結合できるルールです。 バリデーターは単純なルールとメタルールを区別しないことを理解することが重要です。 メタルールは同じ「必須」と同じです（はい、繰り返します）。



nested_object

ネストされたオブジェクトの検証ルールを記述できます。 このルールは常に使用します。

エラーコードは、ネストされたルールに依存します。 ネストされたオブジェクトがハッシュ（辞書）でない場合、フィールドにはエラーが含まれます：「FORMAT_ERROR」。

使用例（ demo ）：

 address: { 'nested_object': { city: 'required', zip: ['required', 'positive_integer'] }}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

list_of

値のリストの検証ルールを記述できます。 各ルールはリスト内の各アイテムに適用されます。

エラーコードは、ネストされたルールに依存します。

使用例（ demo ）：

 { product_ids: { 'list_of': [ 'required', 'positive_integer'] }}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

オブジェクトのリスト

ハッシュ（辞書）の配列の検証規則を記述できます。 「nested_object」のように見えますが、オブジェクトの配列が必要です。 規則は配列内の各要素に適用されます。

エラーコードは、ネストされたルールに依存します。 値が配列ではない場合、フィールドに対してコード「FORMAT_ERROR」が返されます。

使用例（ demo ）：

 products: ['required', { 'list_of_objects': { product_id: ['required','positive_integer'], quantity: ['required', 'positive_integer'] }}]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

list_of_different_objects

「list_of_objects」に似ていますが、私たちに届く配列には、さまざまなタイプのオブジェクトが含まれていることがあります。 オブジェクトのタイプは、「タイプ」などのフィールドによって判別できます。 「List_of_different_objects」を使用すると、さまざまなタイプのオブジェクトのリストのルールを記述できます。

エラーコードは、ネストされた検証ルールに依存します。 ネストされたオブジェクトがハッシュでない場合、フィールドにはエラー「FORMAT_ERROR」が含まれます。

使用例（ demo ）：

 { products: ['required', { 'list_of_different_objects': [ product_type, { material: { product_type: 'required', material_id: ['required', 'positive_integer'], quantity: ['required', {'min_number': 1} ], warehouse_id: 'positive_integer' }, service: { product_type: 'required', name: ['required', {'max_length': 20} ] } } ]}] }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、バリデーターは各ハッシュの「product_type」を調べ、このフィールドの値に応じて、適切な検証ルールを使用します。



エラー形式



既に述べたように、ルールは開発者が理解する文字列エラーコードを返します。たとえば、「REQUIRED」、「WRONG_EMAIL」、「WRONG_DATE」などです。 開発者はエラーが何であるかを理解できるようになり、どのフィールドでエラーが発生したかを伝えるのに便利です。 これを行うために、バリデーターは検証のために渡されたものと同様の構造を返しますが、エラーが発生したフィールドのみを含み、フィールドの元の値ではなく、文字列エラーコードを含みます。



たとえば、次のルールがあります。

 { name: 'required', phone: {max_length: 10}, address: { 'nested_object': { city: 'required', zip: ['required', 'positive_integer'] }} }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

および検証データ：

 { phone: 12345678901, address: { city: 'NYC' } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

出力では、次のエラーが発生します

 { "name": "REQUIRED", "phone": "TOO_LONG", "address": { "zip": "REQUIRED" } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

デモ検証



REST APIとエラー形式



正気なエラーを返すには、常に開発者の追加の努力が必要です。 また、詳細なエラー情報を提供するごく少数のREST API。 多くの場合、これは単なる「悪いリクエスト」であり、それだけです。 データが階層化され、オブジェクトの配列を含む可能性があるため、どのフィールドに属しているか、フィールドパスだけでは十分ではないというエラーを確認したいと思います... 検証エラーの場合、エラーオブジェクトをクライアントに返します。 エラーオブジェクトには、グローバルエラーコードと、LIVRバリデーターから受信したエラーが含まれます。



たとえば、データをサーバーに転送します。

 { "email": "user_at_mail_com", "age": 10, "address": { "country": "USQ" } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それに応じて、以下を取得します（ livr playgroundのデモ検証 ）：

 {"error": { "code": "FORMAT_ERROR", "fields": { "email": "WRONG_EMAIL", "age": "TOO_LOW", "fname": "REQUIRED", "lname": "REQUIRED", "address": { "country": "NOT_ALLOWED_VALUE", "city": "REQUIRED", "zip": "REQUIRED" } } }}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、ある種の「悪いリクエスト」よりもはるかに有益です。



エイリアスを操作し、独自のルールを登録します



仕様には最も使用されるルールのみが含まれていますが、各プロジェクトには独自の仕様があり、いくつかのルールが欠落している場合は常に状況が発生します。 この点で、バリデーターの重要な要件の1つは、任意のタイプの独自のルールでバリデーターを拡張できる可能性でした。 当初、各実装にはルールを記述する独自のメカニズムがありましたが、仕様バージョン0.4から、他のルールに基づいてルールを作成する（エイリアスを作成する）標準的な方法を導入しました。これは状況の70％をカバーします。 両方のオプションを検討してください。



エイリアスを作成する

エイリアスの登録方法は実装によって異なりますが、エイリアスの記述方法は仕様によって規制されています。 たとえば、このアプローチにより、エイリアスの説明をシリアル化し、異なる実装で使用することができます（たとえば、PerlバックエンドとJavaScriptフロントエンドで）

 //   "valid_address" validator. registerAliasedRule({ name: 'valid_address', rules: { nested_object: { country: 'required', city: 'required', zip: 'positive_integer' }} }); //   "adult_age" validator.registerAliasedRule( { name: 'adult_age', rules: [ 'positive_integer', { min_number: 18 } ] }); //   ,   . { name: 'required', age: ['required', 'adult_age' ], address: ['required', 'valid_address'] }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、ルールに独自のエラーコードを設定できます。



例えば

 validator.registerAliasedRule({ name: 'valid_address', rules: { nested_object: { country: 'required', city: 'required', zip: 'positive_integer' }}, error: 'WRONG_ADDRESS' });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アドレスの検証でエラーが発生した場合、次のようになります。

 { address: 'WRONG_ADDRESS' }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

JavaScript実装を例として使用して完全なルールを登録する

検証には、値を検証するコールバック関数が使用されます。 「strong_password」という新しいルールを説明してみましょう。 値が8文字を超えており、大文字と小文字の数字と文字が含まれていることを確認します。

 var LIVR = require('livr'); var rules = {password: ['required', 'strong_password']}; var validator = new LIVR.Validator(rules); validator.registerRules({ strong_password: function() { return function(val) { //   .           "required" if (val === undefined || val === null || val === '' ) return; if ( length(val) < 8 || !val.match([0-9]) || !val.match([az] || !val.match([AZ] ) ) { return 'WEAK_PASSWORD'; } return; } } });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、パスワードの最小文字数を設定する機能を追加し、このルールをグローバル（バリデーターのすべてのインスタンスで使用可能）として登録します。

 var LIVR = require('livr'); var rules = {password: ['required', {'strong_password': 10}]}; var validator = new LIVR.Validator(rules); var strongPassword = function(minLength) { if (!minLength) throw "[minLength] parameter required"; return function(val) { //   .           "required" if (val === undefined || val === null || val === '' ) return; if ( length(val) < minLength || !val.match([0-9]) || !val.match([az] || !val.match([AZ] ) ) { return 'WEAK_PASSWORD'; } return; } }; LIVR.Validator.registerDefaultRules({ strong_password: strongPassword });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、非常に簡単に、新しいルールが登録されます。 より複雑なルールを記述する必要がある場合、最適なオプションは、バリデーターに実装されている標準ルールのリストを表示することです。

• 共通
• 数値
• ひも
• 特別な
• ヘルパー
• フィルター

値を検証するだけでなく、値を変更するルールを登録することもできます。 たとえば、大文字にするか、余分なスペースを削除します。



仕様に従った実装



バリデーターの実装を作成したい場合は、タスクを容易にするために一連のテストケースが作成されました。 実装がすべてのテストに合格した場合、それは正しいとみなすことができます。 テストスイートは4つのグループで構成されています。

• 「ポジティブ」-基本ルールのポジティブテスト
• 「負」-基本ルールの負のテスト
• "Aliases_positive"-ルールエイリアスのポジティブテスト
• "Aliases_negative"-ルールエイリアスのネガティブテスト

実際、各テストにはいくつかのファイルが含まれています。

• rules.json-検証ルールの説明
• input.json-検証のためにバリデーターに渡される構造
• output.json-検証後に取得されるクリーンな構造

「output.json」の代わりの各負のテストには、検証の結果として発生するエラーの説明とともに「errors.json」が含まれます。 エイリアステストには、エイリアスを事前に登録する必要のある「aliases.json」ファイルがあります。



なぜJSONスキーマではないのですか？



よくある質問。 要するに、いくつかの理由があります。

• ルールの複雑な形式。 ルールのある構造を、データのある構造にできるだけ近づけたい。 この例をJSONスキーマで説明してみてください
• エラー形式は指定されておらず、実装が異なるとエラーが異なる形式で返されます。
• 「to_lc」などのデータ変換はありません。

JSONスキーマには、リスト内の要素の最大数を指定する機能など、興味深いものも含まれていますが、LIVRでは、これは別のルールを追加するだけで実装されます。



LIVRリンク

• LIVR仕様（最新バージョン-0.4）
• テストスイート
• LIVRプレイグラウンド
• Javascriptの実装
• Perlの実装
• PHPの実装
• Pythonの実装
• PragmaticPerlマガジンのLIVRおよびPerl実装に関する記事
• OSDN-UA 2013でのLIVRに関するビデオレポート

UPD：



LIVR 2.0（ http://livr-spec.org/ ）がリリースされました。 新機能：

• 型を扱うための一貫したアプローチ。
• 「基本ルール」は「共通ルール」に名前が変更されました。
• 「フィルター規則」は「修飾子」に名前が変更されました。 何も検証しないため、データを変更するだけです。
• 「ヘルパールール」の名前が「メタルール」に変更されました
• ルール「any_object」を追加し、これがオブジェクトであることを確認します
• 追加されたルール-文字列、任意のタイプの文字列
• ルール「eq」を追加-文字列の等価性をチェック
• メタルール「variable_object」を追加しました。 オブジェクトのフィールドに応じて、使用する検証を動的に決定します。
• メタルール「or」を追加しました。 最初に一致するまでルールを1つずつ適用できます。
• ユーザーが何も渡さなかった場合のデフォルト値を設定するために、修飾子「default」が追加されました。
• テストセットが大幅に拡張されました。

JavaScript実装はすでにすべての新しい関数をサポートしていますが、実装の残りの部分は更新中です。