Node 中怎么在Controller 層進(jìn)行數(shù)據(jù)校驗(yàn)

Node 中怎么在Controller 層進(jìn)行數(shù)據(jù)校驗(yàn)，針對(duì)這個(gè)問題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡單易行的方法。

數(shù)據(jù)校驗(yàn)層

后端由于重業(yè)務(wù)邏輯以及待處理各種數(shù)據(jù)，以致于分成各種各樣的層級(jí)，以我經(jīng)歷過的后端項(xiàng)目就有分為  Controller、Service、Model、Helper、Entity 等各種命名的層，五花八門。但這里肯定有一個(gè)層稱為  Controller，站在后端最上層直接接收客戶端傳輸數(shù)據(jù)。

由于 Controller 層是服務(wù)器端中與客戶端數(shù)據(jù)交互的最頂層，秉承著 Fail  Fast的原則，肩負(fù)著數(shù)據(jù)過濾器的功能，對(duì)于不合法數(shù)據(jù)直接打回去，如同秦瓊與尉遲恭門神般威嚴(yán)。

數(shù)據(jù)校驗(yàn)同時(shí)衍生了一個(gè)半文檔化的副產(chǎn)品，你只需要看一眼數(shù)據(jù)校驗(yàn)層，便知道要傳哪些字段，都是些什么格式。

以下都是常見的數(shù)據(jù)校驗(yàn)，本文講述如何對(duì)它們進(jìn)行校驗(yàn)：

• required/optional

• 基本的數(shù)據(jù)校驗(yàn)，如 number、string、timestamp 及值需要滿足的條件

• 復(fù)雜的數(shù)據(jù)校驗(yàn)，如 IP、手機(jī)號(hào)、郵箱與域名

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

山月接觸過一個(gè)沒有數(shù)據(jù)校驗(yàn)層的后端項(xiàng)目，if/else 充斥在各種層級(jí)，萬分痛苦，分分鐘向重構(gòu)。

JSON Schema

JSON Schema 基于 JSON 進(jìn)行數(shù)據(jù)校驗(yàn)格式，并附有一份規(guī)范 json-schema.org[1]，目前  (2020-08) 最新版本是 7.0。各種服務(wù)器編程語言都對(duì)規(guī)范進(jìn)行了實(shí)現(xiàn)，如 go、java、php 等，當(dāng)然偉大的 javascript  也有，如不溫不火的 ajv[2]。

以下是校驗(yàn)用戶信息的一個(gè) Schema，可見語法復(fù)雜與繁瑣：

{   "$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": "用戶手機(jī)號(hào)",       "type": "string",       "pattern": "^(?:(?:\+|00)86)?1[3-9]\d{9}$",       "maxLength": 15     }   },   "required": ["id", "name"] }

對(duì)于復(fù)雜的數(shù)據(jù)類型校驗(yàn)，JSON Schema 內(nèi)置了以下 Format，方便快捷校驗(yàn)：

• Dates and times

• Email addresses

• Hostnames

• IP Addresses

• Resource identifiers

• URI template

• JSON Pointer

• Regular Expressions

對(duì)于不在內(nèi)置 Format 中的手機(jī)號(hào)，使用 ajv.addFormat 可手動(dòng)添加 Format：

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

Joijoi

自稱最強(qiáng)大的 JS 校驗(yàn)庫，在 github 也斬獲了一萬六顆星星。相比 JSON Schema  而言，它的語法更加簡潔并且功能強(qiáng)大。

完成相同的校驗(yàn)，僅需要更少的代碼，并能夠完成更加強(qiáng)大的校驗(yàn)。以下僅做示例，更多示例請(qǐng)前往文檔。

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 相同的校驗(yàn)   repeatPassword: Joi.ref('password'), })   // 密碼與重復(fù)密碼需要同時(shí)發(fā)送   .with('password', 'repeat_password');   // 郵箱與手機(jī)號(hào)提供一個(gè)即可   .xor('email', 'mobilePhone')

數(shù)據(jù)校驗(yàn)與路由層集成

由于數(shù)據(jù)直接從路由傳遞，因此 koajs 官方基于 joi 實(shí)現(xiàn)了一個(gè)  joi-router[4]，前置數(shù)據(jù)校驗(yàn)到路由層，對(duì)前端傳遞來的 query、body 與 params 進(jìn)行校驗(yàn)。

joi-router 也同時(shí)基于 co-body 對(duì)前端傳輸?shù)母鞣N content-type 進(jìn)行解析及限制。如限制為  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;   }, });

正則表達(dá)式與安全正則表達(dá)式

山月在一次排查性能問題時(shí)發(fā)現(xiàn)，一條 API  竟在數(shù)據(jù)校驗(yàn)層耗時(shí)過久，這是我未曾想到的。而問題根源在于不安全的正則表達(dá)式，那什么叫做不安全的正則表達(dá)式呢?

比如下邊這個(gè)能把 CPU 跑掛的正則表達(dá)式就是一個(gè)定時(shí)炸彈，回溯次數(shù)進(jìn)入了指數(shù)爆炸般的增長。

const safe = require('safe-regex') const re = /(x+x+)+y/  // 能跑死 CPU 的一個(gè)正則 re.test('xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx')  // 使用 safe-regex 判斷正則是否安全 safe(re)   // false

數(shù)據(jù)校驗(yàn)，針對(duì)的大多是字符串校驗(yàn)，也會(huì)充斥著各種各樣的正則表達(dá)式，保證正則表達(dá)式的安全相當(dāng)緊要。safe-regex[6]  能夠發(fā)現(xiàn)哪些不安全的正則表達(dá)式。

關(guān)于Node 中怎么在Controller 層進(jìn)行數(shù)據(jù)校驗(yàn)問題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。