Node 如何在 Controller 層進(jìn)行數(shù)據(jù)校驗(yàn)
幽默風(fēng)趣的后端程序員一般自嘲為 CURD Boy。CURD, 也就是對(duì)某一存儲(chǔ)資源的增刪改查，這完全是面向數(shù)據(jù)編程啊。
真好呀，面向數(shù)據(jù)編程，往往會(huì)對(duì)業(yè)務(wù)理解地更加透徹，從而寫(xiě)出更高質(zhì)量的代碼，造出更少的 BUG。既然是面向數(shù)據(jù)編程那更需要避免臟數(shù)據(jù)的出現(xiàn)，加強(qiáng)數(shù)據(jù)校驗(yàn)。否則，難道要相信前端的數(shù)據(jù)校驗(yàn)嗎，畢竟前端數(shù)據(jù)校驗(yàn)直達(dá)用戶(hù)，是為了 UI 層更友好的用戶(hù)反饋。
數(shù)據(jù)校驗(yàn)層
后端由于重業(yè)務(wù)邏輯以及待處理各種數(shù)據(jù)，以致于分成各種各樣的層級(jí)，以我經(jīng)歷過(guò)的后端項(xiàng)目就有分為 Controller、Service、Model、Helper、Entity 等各種命名的層，五花八門(mén)。但這里肯定有一個(gè)層稱(chēng)為 Controller，站在后端最上層直接接收客戶(hù)端傳輸數(shù)據(jù)。
由于 Controller 層是服務(wù)器端中與客戶(hù)端數(shù)據(jù)交互的最頂層，秉承著 Fail Fast的原則，肩負(fù)著數(shù)據(jù)過(guò)濾器的功能，對(duì)于不合法數(shù)據(jù)直接打回去，如同秦瓊與尉遲恭門(mén)神般威嚴(yán)。
數(shù)據(jù)校驗(yàn)同時(shí)衍生了一個(gè)半文檔化的副產(chǎn)品，你只需要看一眼數(shù)據(jù)校驗(yàn)層，便知道要傳哪些字段，都是些什么格式。
以下都是常見(jiàn)的數(shù)據(jù)校驗(yàn)，本文講述如何對(duì)它們進(jìn)行校驗(yàn)：
- required/optional
- 基本的數(shù)據(jù)校驗(yàn)，如 number、string、timestamp 及值需要滿(mǎn)足的條件
- 復(fù)雜的數(shù)據(jù)校驗(yàn)，如 IP、手機(jī)號(hào)、郵箱與域名
- const body = {
- id,
- name,
- mobilePhone,
- }
山月接觸過(guò)一個(gè)沒(méi)有數(shù)據(jù)校驗(yàn)層的后端項(xiàng)目，if/else 充斥在各種層級(jí)，萬(wàn)分痛苦，分分鐘向重構(gòu)。
JSON Schema
JSON Schema 基于 JSON 進(jìn)行數(shù)據(jù)校驗(yàn)格式，并附有一份規(guī)范 json-schema.org[1]，目前 (2020-08) 最新版本是 7.0。各種服務(wù)器編程語(yǔ)言都對(duì)規(guī)范進(jìn)行了實(shí)現(xiàn)，如 go、java、php 等，當(dāng)然偉大的 javascript 也有，如不溫不火的 ajv[2]。
以下是校驗(yàn)用戶(hù)信息的一個(gè) Schema，可見(jiàn)語(yǔ)法復(fù)雜與繁瑣：
- {
- "$schema": "http://json-schema.org/draft-04/schema#",
- "title": "User",
- "description": "用戶(hù)信息",
- "type": "object",
- "properties": {
- "id": {
- "description": "用戶(hù) ID",
- "type": "integer"
- },
- "name": {
- "description": "用戶(hù)姓名",
- "type": "string"
- },
- "email": {
- "description": "用戶(hù)郵箱",
- "type": "string",
- "format": "email",
- "maxLength": 20
- },
- "mobilePhone": {
- "description": "用戶(hù)手機(jī)號(hào)",
- "type": "string",
- "pattern": "^(?:(?:\+|00)86)?1[3-9]\d{9}$",
- "maxLength": 15
- }
- },
- "required": ["id", "name"]
- }
對(duì)于復(fù)雜的數(shù)據(jù)類(lèi)型校驗(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
自稱(chēng)最強(qiáng)大的 JS 校驗(yàn)庫(kù)，在 github 也斬獲了一萬(wàn)六顆星星。相比 JSON Schema 而言，它的語(yǔ)法更加簡(jiǎn)潔并且功能強(qiáng)大。
| The most powerful data validation library for JS |
完成相同的校驗(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ì)前端傳遞來(lái)的 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á)式
山月在一次排查性能問(wèn)題時(shí)發(fā)現(xiàn)，一條 API 竟在數(shù)據(jù)校驗(yàn)層耗時(shí)過(guò)久，這是我未曾想到的。而問(wèn)題根源在于不安全的正則表達(dá)式，那什么叫做不安全的正則表達(dá)式呢?
比如下邊這個(gè)能把 CPU 跑掛的正則表達(dá)式就是一個(gè)定時(shí)炸彈，回溯次數(shù)進(jìn)入了指數(shù)爆炸般的增長(zhǎng)。
- 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á)式。
總結(jié)
- Controller 層需要進(jìn)行統(tǒng)一的數(shù)據(jù)校驗(yàn)，可以采用 JSON Schema (Node 實(shí)現(xiàn) ajv) 與 Joi
- JSON Schema 有官方規(guī)范及各個(gè)語(yǔ)言的實(shí)現(xiàn)，但語(yǔ)法繁瑣，可使用校驗(yàn)功能更為強(qiáng)大的 Joi
- 進(jìn)行字符串校驗(yàn)時(shí)，注意不安全的正則引起的性能問(wèn)題
