php域名ip校验技巧_Node 若安在 Controller 层进行数据校验

作者：山月行

转发链接：https://mp.weixin.qq.com/s/UAU_Vpu3o53zqEAKDYgvQQ

诙谐风趣的后端程序员一样平常自嘲为 CURD Boy。
CURD, 也便是对某一存储资源的增编削查，这完备是面向数据编程啊。

真好呀，面向数据编程，每每会对业务理解地更加透彻，从而写出更高质量的代码，造出更少的 BUG。
既然是面向数据编程那更须要避免脏数据的涌现，加强数据校验。
否则，难道要相信前真个数据校验吗，毕竟前端数据校验直达用户，是为了 UI 层更友好的用户反馈。

后端由于重业务逻辑以及待处理各种数据，甚至于分成各种各样的层级，以我经历过的后端项目就有分为 Controller、Service、Model、Helper、Entity 等各种命名的层，五花八门。
但这里肯定有一个层称为 Controller，站在后端最上层直接吸收客户端传输数据。

由于 Controller 层是做事器端中与客户端数据交互的最顶层，秉承着 Fail Fast 的原则，肩负着数据过滤器的功能，对付不合法数据直接打回去，犹如秦琼与尉迟恭门神般威严。

数据校验同时衍生了一个半文档化的副产品，你只须要看一眼数据校验层，便知道要传哪些字段，都是些什么格式。

以下都是常见的数据校验，本文讲述如何对它们进行校验：

constbody={id,name,mobilePhone,email}

山月打仗过一个没有数据校验层的后端项目，if/else 充斥在各种层级，万分痛楚，分分钟想重构。

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，方便快捷校验

对付不再内置 Format 中的手机号，利用 ajv.addFormat 可手动添加 Format

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

joi[3] 自称最强大的 JS 校验库，在 github 也斩获了一万六颗星星。
比较 JSON Schema 而言，它的语法更加简洁并且功能强大。

❝

The most powerful data validation library for JS

❞

完成相同的校验，仅须要更少的代码，并能够完成更加强大的校验。
以下仅做示例，更多示例请前往文档。

constschema=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 攻击。

constrouter=require('koa-joi-router');constpublic=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)=>{awaitcheckAuth(ctx);returnnext();},handler:async(ctx)=>{awaitcreateUser(ctx.request.body);ctx.status=201;},});正则表达式与安全正则表达式

山月在一次排查性能问题时创造，一条 API 竟在数据校验层耗时过久，这是我未曾想到的。
而问题根源在于不屈安的正则表达式，那什么叫做不屈安的正则表达式呢？

比如下边这个能把 CPU 跑挂的正则表达式便是一个定时炸弹，回溯次数进入了指数爆炸般的增长。

❝

可以参考文章 浅析 ReDos 事理与实践[5]

❞

constsafe=require('safe-regex')constre=/(x+x+)+y///能跑去世CPU的一个正则re.test('xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx')//利用safe-regex判断正则是否安全safe(re)//false

数据校验，针对的大多是字符串校验，也会充斥着各种各样的正则表达式，担保正则表达式的安全相称紧要。
safe-regex[6] 能够创造哪些不屈安的正则表达式。

作者：山月行

转发链接：https://mp.weixin.qq.com/s/UAU_Vpu3o53zqEAKDYgvQQ