中间件执行流程
中间件的执行流程,可以用下面这张图片来生动的说明(图片使用了 Koa 2 的 async 语法):
对于 Koa 1 来说也类似,只是 async 函数换作 generator 函数,await 换作 yield 关键字。
对于前端程序员,可以把 yield 之前的代码认为是捕获阶段,yield 之后的认为的冒泡阶段,从而理解多个中间件之间代码的执行流程。
路由中间件
路由一般属于业务代码,我们一般放在其他基础中间件之后来注册。路由的基本原理就是判断 url path, 然后决定是否执行某个中间件逻辑。
简单实现可以类似这样:
const Koa = require('koa')
const app = new Koa()
app.use(function *(next) {
if (this.path === '/home') {
this.body = '首页'
}
else {
yield next
}
console.log('这里会执行哦')
})
app.use(function *(next) {
if (this.path === '/admin') {
this.body = '管理端'
}
})
app.listen(3000)
可以看到,对于不符合本中间件的请求 path, 就直接丢弃,并去执行下一个中间件。如果所有中间件都匹配不到,会返回 404(Koa 默认行为).
上面代码有一个问题,就是 "console.log" 会一直执行,要解决这个也很简单。因为对于路由中间件来说,所有逻辑都是匹配path的if判断内部的,所以对于这个不匹配的else代码,可以直接当做该 generator 的结束。可以在 yield 前面加 return 或这样修改:
app.use(function* (next) {
if (this.path !== '/') return yield next;
this.body = 'we are at home!';
})
koa-router
为了应对更复杂的路由功能,我们需要引入第三方的 koa-router 路由模块。不过 Koa1 需要使用 4.x 版本的。
Issue: You are using koa@1.x but koa-views@5.x needs koa@2 or above. If you are still at v1 please consider using koa-views@4.x. Note however, there are no updates supporting v1
npm i koa-router@4 -d
koa-router 暴露一个 Router 类,像 Vue.js 一样,只需创建一个 router 实例,就可以注册对应的路由规则。
var app = require('koa')();
var Router = require('koa-router');
var myRouter = new Router();
myRouter.get('/', function *(next) {
this.response.body = 'Hello World!';
});
app.use(myRouter.routes());
app.listen(3000);
从用法中显然能看出来,routers 方法返回的应该就是一个 generator 中间件函数,只是内部由 koa-router 进行了路由规则的处理和逻辑执行。开发者只需关注如何向 koa-router 对象上注册 处理中间件
。
koa-router 像多数路由一样支持很多 http 方法和匹配规则:
router.get()
router.post()
router.put()
router.del()
router.patch()
视图渲染中间件
Koa 有很多的中间件 比如 [koa-view](
https://github.com/queckezz/k...
该中间件支持多种模板引擎。
cookie
cookie的获取和设置是 Koa 内置的context集成的能力,不需要中间件的参与。
this.cookies.get('cookieName')
this.cookies
koa-router
为了兼容 Koa1,我们需要安装一个老一点的koa-router
npm i koa-router@5.x
koa-logger
用于打印请求日志和耗时
npm i koa-logger@1 // 1.x 支持 Koa1
session
// 为了兼容 Koa1
npm i koa-session@3.x
该版本的 koa-session 只需要执行其导出函数并传入一个 app 对象即可使用
const session = require('koa-session')
app.use(session(app))
app.use(function * (next) {
console.log(this.session.xxx)
})
koa-compress
默认的Koa应用,我们观察下浏览器的 Response 响应的话,会发现虽然请求时浏览器携带了 Accept-Encoding: gzip
, 但实际上响应里面并没有 Content-Encoding: gzip
, 也就是说并没有压缩。
安装 koa-compress@1.x
之后,就可以让 Koa 默认开启对响应内容的压缩了:
app.use(require('koa-compress')())
大一点的文件才有效果哦,太小的话还比不上 'Content-Encoding' 头所占的字节的话,就有点得不偿失了。
koa-csrf
# 为了兼容 Koa1 请安装 2.x 版本
npm i koa-csrf@2.x
该模块的导出对象是一个函数,函数会创建一个中间件,你需要将他注册到 Koa 的app里面。使用方式如下:
app.use(session(app)) // koa-csrf 的机制要依赖session能力
app.use(csrf()) // 这是koa1的用法
koa-csrf原理:
解决跨站请求伪造攻击,需要在客户端请求时携带一个秘密的token,这个token要确保只有服务器端知道,而且用后即焚. 其思路是,一个用户在访问页面时,服务端先把这个 csrf-token 放置到页面中,然后页面再次发起 POST 请求时,页面需要带上这个token,由服务端来校验是不是服务器颁发的token.
回到koa-csrf这个模块,在每次请求周期中, koa-csrf 都会在它的中间件内生成一个秘钥secret, 然后基于secret生成一个 csrf-token; 并把这个 csrf-token 挂在 ctx 上,把 secret 挂在session上(因为secret作为一个秘钥基于session可以针对一个独立用户,没必要每次都变). 我们把koa-csrf 中生成token过程的源码捡出来如下:
// 创建一个秘钥并放在session里,每次生成和校验csrf时都用这个token
var secret = this.session.secret
|| (this.session.secret = tokens.secretSync())
// 摘录tokens.secretSync的实现如下:
Tokens.prototype.secretSync = function secretSync () {
return uid.sync(this.secretLength) // 其实就是使用 uid-safe 模块生成一个固定长度的随机uniqueId
}
有了secret秘钥了,再来看下 csrf-token 咋生成的:
// 基于上一步的秘钥secret来生成csrf-token 放在ctx对象上
this._csrf = tokens.create(secret)
// csrf-token的生成过程如下:
Tokens.prototype.create = function create (secret) {
if (!secret || typeof secret !== 'string') {
throw new TypeError('argument secret is required')
}
// 重点在这里。其中rndm模块仅仅就是用来生成n位数的随机字符串;而_tokenize函数就是用来生成csrf-token的,其实现我摘录在下面
return this._tokenize(secret, rndm(this.saltLength))
}
// tokenize实现
Tokens.prototype._tokenize = function tokenize (secret, salt) {
// csrf-token 的格式为: salt随机字符串 + hash(salt+secret)
return salt + '-' + hash(salt + '-' + secret)
}
至此,csrf-token就生成了。接下来,你需要在 GET 请求的页面上,把 this.csrf 渲染到页面中。然后前端再次请求后端的 POST 接口时,需要带上那个token。这样,POST请求到达服务器时 koa-csrf 中间件就会在请求到来时优先进行校验。
校验规则已经显而易见了:
- 从前端的query或body或cookie中取出 _csrf 这个变量(csrf-token)
- 按照csrf-token的规则,取出
横线
前面的字符串作为salt随机串
,取后面的作为待校验的哈希[fehash]
- 从服务端的session中(this.session.secret)拿出秘钥
secret
- 使用与当初一模一样的tokenize函数算一下这个哈希:
var result = hash('前端传来的salt' + '服务端秘钥secret')
- 比对本次算出来的 result 与 前端传来的 待校验fehash值 是否一致。不一致则说明是伪造的请求。koa-csrf 中间件会直接跑错
那么,会不会存在黑客在中间网络窃取到某次请求的token后,再利用这个token来实施 CSRF 呢? 这个实际上是无法避免的,既然黑客能窃取到http报文(说明请求被中间人劫持或站点被XSS注入),那黑客完全可以窃取到 cookie 等信息,相当于完全模拟了用户,这种情况下任何防范都没有作用了;只能说如果发现IP变了那就要求用户重新登录且切换 secret。
更多中间件
几乎所有的网络应用所需的功能都有中间件提供。可以在官方 wiki 中看到中间件列表
中间件编写最佳实践
带参数的中间件
对于编写公共中间件的场景来说,更多的需要用户能自定义中间件中一些配置。此时需要支持用户对中间件进行配置。要实现可配置的中间件也简单,只需要写一个包装函数,返回一个 generator 的函数即可。例如我们的日志中间件,可以允许用户自定义日志格式,则可以这样:
// 可自定义日志格式的中间件
const mylogger = function (format) {
format = format || '{{method}} {{url}} - {{time}}'
return function *(next) {
const start = Date.now()
yield next
const ms = Date.now() - start
console.log(format
.replace('{{method}}', this.method)
.replace('{{url}}', this.url)
.replace('{{time}}', ms)
)
}
}
// 使用该中间件
app.use(mylogger('{{time}} - {{method}} : {{url}}'))
合并多个中间件
有时可能需要将多个中间件合并为一个。对于 Generator来说,可以使用 .call(this. next) 的方式将他们合并。
const Koa = require('koa')
const app = new Koa()
function *a(next) {
console.log('come a')
yield next;
console.log('end a')
}
function *b(next) {
console.log('come b')
yield next
console.log('end b')
}
function *all(next) {
console.log('come all')
yield a.call(this, b.call(this, next));
console.log('end all')
}
app.use(all)
app.listen(3000)
执行上述代码,控制台会输出:
come all
come a
come b
end b
end a
end all
你一定比较疑惑为什么多个 generator 函数通过 call(this, next)
是怎么做到如此合并执行的? 其实本质上 Koa 的运作也是基于合并 middlware 来执行的。这里大概是这样的:
- 首先我们需要知道 a、b、all 都是 generator 函数;而 next 是 generator 对象
- a.call(this, b.call(this, next)) 相当于先执行 b.call(this, next) 创建 b 的 generator 对象。然后该对象会作为 next 参数去执行 a 函数,进而创建出 a 的 generator 对象
- 因此 a.call(this, b.call(this, next)) 的返回值是 a 函数的 generator 对象;且 a 函数中的 next 表示的是 b 函数的 generator 对象。 这样执行这个表达式的返回值,便相当于执行:
function *a(next) {
console.log('come a')
yield (b中间件 的 generator 对象);
console.log('end a')
}
- 如此,all 这个 generator 函数就把各个中间件联合起来执行了。
上述过程类似于 koa-compse 模块的合并能力, 这里贴一个 compose 模块的实现(引用自阮一峰的 Koa 教程):
function compose(middleware){
return function *(next){
if (!next) next = noop();
var i = middleware.length;
while (i--) {
next = middleware[i].call(this, next);
}
yield *next;
}
}
function *noop(){}
以上就是中间件合并的原理了,合并后会返回一个新的 generator 函数。而 Koa 是如何使用 co
库把合并后的 generator 中间件函数运行起来的呢? 这个就有点复杂了,更详细的 middleware合并 和 Koa 原理可以参考: qianlongo github
总结
本章节介绍了几个常用中间件,如koa-router和 koa-view,并对中间件的合并和传参进行了简单介绍。基本上 Koa 的所有使用方式都已经介绍完毕,后面就是赤裸裸的实践了
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。