您好,登錄后才能下訂單哦!
Node 中怎么在Controller 層進行數據校驗,針對這個問題,這篇文章詳細介紹了相對應的分析和解答,希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
數據校驗層
后端由于重業務邏輯以及待處理各種數據,以致于分成各種各樣的層級,以我經歷過的后端項目就有分為 Controller、Service、Model、Helper、Entity 等各種命名的層,五花八門。但這里肯定有一個層稱為 Controller,站在后端最上層直接接收客戶端傳輸數據。
由于 Controller 層是服務器端中與客戶端數據交互的最頂層,秉承著 Fail Fast的原則,肩負著數據過濾器的功能,對于不合法數據直接打回去,如同秦瓊與尉遲恭門神般威嚴。
數據校驗同時衍生了一個半文檔化的副產品,你只需要看一眼數據校驗層,便知道要傳哪些字段,都是些什么格式。
以下都是常見的數據校驗,本文講述如何對它們進行校驗:
required/optional
基本的數據校驗,如 number、string、timestamp 及值需要滿足的條件
復雜的數據校驗,如 IP、手機號、郵箱與域名
const body = { id, name, mobilePhone, email }
山月接觸過一個沒有數據校驗層的后端項目,if/else 充斥在各種層級,萬分痛苦,分分鐘向重構。
JSON Schema
JSON Schema 基于 JSON 進行數據校驗格式,并附有一份規范 json-schema.org[1],目前 (2020-08) 最新版本是 7.0。各種服務器編程語言都對規范進行了實現,如 go、java、php 等,當然偉大的 javascript 也有,如不溫不火的 ajv[2]。
以下是校驗用戶信息的一個 Schema,可見語法復雜與繁瑣:
{ "$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 Schema 內置了以下 Format,方便快捷校驗:
Dates and times
Email addresses
Hostnames
IP Addresses
Resource identifiers
URI template
JSON Pointer
Regular Expressions
對于不在內置 Format 中的手機號,使用 ajv.addFormat 可手動添加 Format:
ajv.addFormat('mobilePhone', (str) => /^(?:(?:\+|00)86)?1[3-9]\d{9}$/.test(str));
Joijoi
自稱最強大的 JS 校驗庫,在 github 也斬獲了一萬六顆星星。相比 JSON Schema 而言,它的語法更加簡潔并且功能強大。
The most powerful data validation library for 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[4],前置數據校驗到路由層,對前端傳遞來的 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 跑掛的正則表達式就是一個定時炸彈,回溯次數進入了指數爆炸般的增長。
const safe = require('safe-regex') const re = /(x+x+)+y/ // 能跑死 CPU 的一個正則 re.test('xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx') // 使用 safe-regex 判斷正則是否安全 safe(re) // false
數據校驗,針對的大多是字符串校驗,也會充斥著各種各樣的正則表達式,保證正則表達式的安全相當緊要。safe-regex[6] 能夠發現哪些不安全的正則表達式。
關于Node 中怎么在Controller 層進行數據校驗問題的解答就分享到這里了,希望以上內容可以對大家有一定的幫助,如果你還有很多疑惑沒有解開,可以關注億速云行業資訊頻道了解更多相關知識。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。