這篇文章給大家分享的是有關(guān)Controller層中Node進(jìn)行數(shù)據(jù)校驗(yàn)的方法的內(nèi)容。小編覺(jué)得挺實(shí)用的,因此分享給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧。
站在用戶的角度思考問(wèn)題,與客戶深入溝通,找到蓬溪網(wǎng)站設(shè)計(jì)與蓬溪網(wǎng)站推廣的解決方案,憑借多年的經(jīng)驗(yàn),讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合,創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品,建站類型包括:成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、主機(jī)域名、網(wǎng)頁(yè)空間、企業(yè)郵箱。業(yè)務(wù)覆蓋蓬溪地區(qū)。幽默風(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á)用戶,是為了 UI 層更友好的用戶反饋。
后端由于重業(yè)務(wù)邏輯以及待處理各種數(shù)據(jù),以致于分成各種各樣的層級(jí),以我經(jīng)歷過(guò)的后端項(xiàng)目就有分為 Controller
、Service
、Model
、Helper
、Entity
等各種命名的層,五花八門(mén)。但這里肯定有一個(gè)層稱為 Controller
,站在后端最上層直接接收客戶端傳輸數(shù)據(jù)。
由于 Controller
層是服務(wù)器端中與客戶端數(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):
const body = { id, name, mobilePhone, email }
作者接觸過(guò)一個(gè)沒(méi)有數(shù)據(jù)校驗(yàn)層的后端項(xiàng)目,if/else
充斥在各種層級(jí),萬(wàn)分痛苦,分分鐘向重構(gòu)。
JSON Schema
基于 JSON 進(jìn)行數(shù)據(jù)校驗(yàn)格式,并附有一份規(guī)范 json-schema.org,目前 (2020-08) 最新版本是 7.0。各種服務(wù)器編程語(yǔ)言都對(duì)規(guī)范進(jìn)行了實(shí)現(xiàn),如 go
、java
、php
等,當(dāng)然偉大的 javascript 也有,如不溫不火的 ajv。
以下是校驗(yàn)用戶信息的一個(gè) Schema,可見(jiàn)語(yǔ)法復(fù)雜與繁瑣:
{ "$schema": "/tupian/20230522/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)
對(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));
joi 自稱最強(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ù)直接從路由傳遞,因此 koajs
官方基于 joi
實(shí)現(xiàn)了一個(gè) joi-router,前置數(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; }, });
作者在一次排查性能問(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)。
可以參考文章 淺析 ReDos 原理與實(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 能夠發(fā)現(xiàn)哪些不安全的正則表達(dá)式。
感謝各位的閱讀!關(guān)于Controller層中Node進(jìn)行數(shù)據(jù)校驗(yàn)的方法就分享到這里了,希望以上內(nèi)容可以對(duì)大家有一定的幫助,讓大家可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò),可以把它分享出去讓更多的人看到吧!
分享標(biāo)題:Controller層中Node進(jìn)行數(shù)據(jù)校驗(yàn)的方法-創(chuàng)新互聯(lián)
文章分享:http://muchs.cn/article10/dpjsdo.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供企業(yè)網(wǎng)站制作、靜態(tài)網(wǎng)站、定制開(kāi)發(fā)、虛擬主機(jī)、網(wǎng)站內(nèi)鏈、外貿(mào)網(wǎng)站建設(shè)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容