Comment le nœud de la couche contrôleur effectue-t-il la vérification des données ?

[Recommandation de didacticiel vidéo : tutoriel node js]

Les programmeurs back-end humoristiques se moquent généralement d'eux-mêmes en tant que CURD Boy. CURD, qui consiste en l'ajout, la suppression, la modification et l'interrogation d'une certaine ressource de stockage, est une programmation entièrement orientée données.

C'est génial. La programmation orientée données conduit souvent à une compréhension plus approfondie de l'entreprise, écrivant ainsi du code de meilleure qualité et créant moins de bugs. Puisqu'il s'agit d'une programmation orientée données, il est d'autant plus nécessaire d'éviter l'apparition de données sales et de renforcer la vérification des données. Sinon, devrions-nous faire confiance à la vérification des données frontales ? Après tout, la vérification des données frontales est directement transmise à l'utilisateur pour un retour plus convivial au niveau de l'interface utilisateur.

Couche de vérification des données

En raison de l'accent mis sur la logique métier et les diverses données à traiter, le backend est divisé en différents niveaux, comme le montrent les projets backend que j'ai expérimentés. couches nommées pour Controller, Service, Model, Helper, Entity, etc. Mais il doit y avoir ici une couche appelée Controller, qui se situe au niveau de la couche supérieure du backend et reçoit directement les données transmises par le client.

Étant donné que la couche Controller est la couche supérieure du serveur qui interagit avec les données client, adhérant au principe de Fail Fast, elle est responsable de la fonction de filtre de données et combat directement les données illégales, tout comme Qin Qiong. Aussi majestueux que le dieu de la porte de Yuchi Gong.

La vérification des données génère également un sous-produit semi-documenté. Il suffit de jeter un œil à la couche de vérification des données pour savoir quels champs transmettre et dans quels formats ils se trouvent.

Voici les vérifications de données courantes. Cet article décrit comment les vérifier :

1. obligatoire/facultatif
2. Vérification des données de base, telles que le nombre, la chaîne, l'horodatage. et les conditions que la valeur doit remplir
3. Vérification des données complexes, telles que l'adresse IP, le numéro de téléphone portable, l'e-mail et le nom de domaine

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

L'auteur est tombé sur un système sans données couche de vérification Les projets back-end if/else sont pleins de problèmes à différents niveaux, ce qui est extrêmement pénible et doit être restructuré en quelques minutes.

Schéma JSON

JSON Schema Format de vérification des données basé sur JSON, avec une spécification json-schema.org, actuellement (2020-08) la dernière version Il s'agit de la 7.0 . Divers langages de programmation serveur ont implémenté la spécification, tels que go, java, php, etc., et bien sûr, un excellent javascript l'a également, comme le tiède ajv.

Ce qui suit est un schéma permettant de vérifier les informations utilisateur. On peut voir que la syntaxe est compliquée et lourde :

{
  "$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"]
}

Pour la vérification de types de données complexes, le schéma JSON intègre le format suivant. , ce qui est pratique et rapide pour la vérification

• Dates et heures
• Adresses e-mail
• Noms d'hôtes
• Adresses IP
• Ressource identifiants
• Modèle d'URI
• Pointeur JSON
• Expressions régulières

Pour les numéros de téléphone mobile qui ne sont pas dans le format intégré, utilisez ajv.addFormat pour ajouter manuellement le Format

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

Joi

joi prétend être la bibliothèque de vérification JS la plus puissante et a également gagné 16 000 étoiles sur github. Par rapport au schéma JSON, sa syntaxe est plus concise et puissante.

La bibliothèque de validation de données la plus puissante pour JS

Effectuez la même validation, nécessite seulement moins de code et peut effectuer une validation plus puissante. Les éléments suivants ne sont que des exemples, veuillez consulter la documentation pour plus d'exemples.

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')

Vérification des données et intégration de la couche de routage

Étant donné que les données sont transmises directement depuis la route, koajs a officiellement implémenté un joijoi-router basé sur , avant Définissez la vérification des données sur la couche de routage et vérifiez les query, body et params transmis depuis le front-end.

joi-router analyse et limite également divers co-body transmis par le front-end en fonction de content-type. Si la limite est application/json, les attaques CSRF peuvent également être évitées dans une certaine mesure.

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;
  },
});

Expressions régulières et expressions régulières sûres

Lors du dépannage d'un problème de performances, l'auteur a constaté qu'une API prenait en fait trop de temps dans la couche de vérification des données, ce à quoi je n'avais jamais pensé. La racine du problème réside dans les expressions régulières non sécurisées. Alors, que sont les expressions régulières non sécurisées ?

Par exemple, l'expression régulière suivante qui peut bloquer le processeur est une bombe à retardement, et le nombre de retours en arrière a augmenté de façon exponentielle.

可以参考文章 浅析 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. 进行字符串校验时，注意不安全的正则引起的性能问题

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

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!