コントローラー層のノードはどのようにデータ検証を実行するのでしょうか?

[ビデオ チュートリアルの推奨: node js チュートリアル]

ユーモラスなバックエンド プログラマーは、通常、自分自身を CURD Boy だと笑います。特定のストレージ リソースの追加、削除、変更、クエリを行う CURD は、完全にデータ指向のプログラミングです。

データ指向プログラミングは多くの場合、ビジネスのより徹底的な理解につながり、それによってより高品質のコードを作成し、バグの発生を減らします。データ指向のプログラミングであるため、ダーティデータの出現を避け、データ検証を強化することがさらに必要です。それ以外の場合、フロントエンド データ検証を信頼すべきでしょうか? 結局のところ、フロントエンド データ検証は、UI 層でよりユーザー フレンドリーなフィードバックを得るためにユーザーに直接送信されます。

データ検証層

バックエンドは、ビジネスロジックや処理する各種データに重点​​を置くため、さまざまなレベルに分かれており、私が経験したバックエンドプロジェクトは数多くあります。 Controller、Service、Model、Helper、Entity など。ただし、ここには Controller と呼ばれる層が存在する必要があります。これはバックエンドの最上位層に位置し、クライアントによって送信されたデータを直接受信します。

Controller 層はサーバー側でクライアント データと対話する最上位層であるため、Fail Fast の原則に従い、機能を担当します。違法なデータは直接返送され、扉の神 Qin Qiong と Yuchi Gong のように荘厳です。

データ検証では、半文書化された副産物も得られます。データ検証レイヤーを確認するだけで、どのフィールドが送信されるか、どのような形式で送信されるかを知ることができます。

次は一般的なデータ検証です。この記事では、その検証方法について説明します:

1. 必須/オプション
2. 数値、文字列、タイムスタンプなどの基本的なデータ検証値が満たす必要がある条件
3. IP、携帯電話番号、電子メール、ドメイン名などの複雑なデータ検証

const body = {
  id,
  name,
  mobilePhone,
  email
}

作成者はあるシステムに接触しましたデータ検証レイヤーなし バックエンド プロジェクト、if/else がさまざまなレベルでフラッディングされるため、非常に手間がかかり、数分でリファクタリングが必要になります。

JSON スキーマ

JSON スキーマ データ検証形式の JSON に基づいており、仕様は json-schema.org です。現在 (2020 年 8 月) ）最新バージョンは7.0です。 go、java、php など、さまざまなサーバー プログラミング言語でこの仕様が実装されています。もちろん、次のような優れた JavaScript もあります。ぬるい ajv。

次はユーザー情報を検証するためのスキーマです。構文が複雑で扱いにくいことがわかります:

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "title": "User",
  "description": "用户信息",
  "type": "object",
  "properties": {
    "id": {
      "description": "用户 ID",
      "type": "integer"
    },
    "name": {
      "description": "用户姓名",
      "type": "string"
    },
    "email": {
      "description": "用户邮箱",
      "type": "string",
      "format": "email",
      "maxLength": 20
    },
    "mobilePhone": {
      "description": "用户手机号",
      "type": "string",
      "pattern": "^(?:(?:\+|00)86)?1[3-9]\d{9}$",
      "maxLength": 15
    }
  },
  "required": ["id", "name"]
}

複雑なデータ型の検証のために、JSON スキーマには次の形式が組み込まれています便利で素早い確認のため

• 日付と時刻
• 電子メール アドレス
• ホスト名
• IP アドレス
• リソース識別子
• URI テンプレート
• JSON ポインター
• 正規表現

組み込み形式にない携帯電話番号の場合は、ajv を使用してください.addFormat を使用して Format

ajv.addFormat('mobilePhone', (str) => /^(?:(?:\+|00)86)?1[3-9]\d{9}$/.test(str));

Joi

#joi は最も強力な JS 検証ライブラリであると主張しており、github で 16,000 個のスターも獲得しています。 JSON スキーマと比較して、その構文はより簡潔で強力です。

JS 用の最も強力なデータ検証ライブラリ

同じ検証を完了するだけで、必要なコードが少なくなり、より強力な検証を完了できます。以下は単なる例です。その他の例についてはドキュメントを参照してください。

const schema = Joi.object({
  id: Joi.number().required(),
  name: Joi.number().required(),
  email: Joi.string().email({ minDomainSegments: 2, tlds: { allow: ['com', 'net'] } }),
  mobilePhone: Joi.string().pattern(/^(?:(?:\+|00)86)?1[3-9]\d{9}$/),

  password: Joi.string().pattern(/^[a-zA-Z0-9]{3,30}$/),
  // 与 password 相同的校验
  repeatPassword: Joi.ref('password'),
})
  // 密码与重复密码需要同时发送
  .with('password', 'repeat_password');
  // 邮箱与手机号提供一个即可
  .xor('email', 'mobilePhone')

データ検証とルーティング層の統合

データはルーティングから直接渡されるため、koajs は joi## に基づいて を正式に実装しました。 # joi-router、プレデータはルーティング層に対して検証され、フロントエンドから渡される query、body、params は次のようになります。確認されました。

joi-router は、co-body に基づいて、フロントエンドによって送信されるさまざまな content-type も解析し、制限します。 application/json に限定すれば、CSRF 攻撃もある程度防ぐことができます。

const router = require('koa-joi-router');
const public = router();

public.route({
  method: 'post',
  path: '/signup',
  validate: {
    header: joiObject,
    query: joiObject,
    params: joiObject,
    body: joiObject,
    maxBody: '64kb',
    output: { '400-600': { body: joiObject } },
    type: 'json',
    failure: 400,
    continueOnError: false
  },
  pre: async (ctx, next) => {
    await checkAuth(ctx);
    return next();
  },
  handler: async (ctx) => {
    await createUser(ctx.request.body);
    ctx.status = 201;
  },
});

正規表現と安全な正規表現

著者がパフォーマンスの問題のトラブルシューティングを行っていたとき、データ検証レイヤーで API に実際に時間がかかりすぎることに気づきましたが、これは私が思いもしなかったことでした。問題の根本は安全でない正規表現にあります。では、安全でない正規表現とは何でしょうか?

たとえば、CPU をハングアップさせる可能性がある以下の正規表現は時限爆弾であり、バックトラッキングの数は指数関数的に増加しています。

可以参考文章 浅析 ReDos 原理与实践

const safe = require('safe-regex')
const re = /(x+x+)+y/

// 能跑死 CPU 的一个正则
re.test('xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx')

// 使用 safe-regex 判断正则是否安全
safe(re)   // false

数据校验，针对的大多是字符串校验，也会充斥着各种各样的正则表达式，保证正则表达式的安全相当紧要。safe-regex 能够发现哪些不安全的正则表达式。

总结

1. Controller 层需要进行统一的数据校验，可以采用 JSON Schema (Node 实现 ajv) 与 Joi
2. JSON Schema 有官方规范及各个语言的实现，但语法繁琐，可使用校验功能更为强大的 Joi
3. 进行字符串校验时，注意不安全的正则引起的性能问题

更多编程相关知识，可访问：编程教学！！

以上がコントローラー層のノードはどのようにデータ検証を実行するのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。