cors跨域_通过中间件设置cors跨域，让跨域资源共享变得更简单

上一篇文章《详解CORS跨域内部机制，帮助前端克服浏览器同源策略》作者详细介绍了如何利用cors进行接口跨域，其中服务器需要设置几个响应头。显然，这是一个很通用的功能，所以这篇文章我们把它封装成一个中间件。

我们接着上篇文章的demo继续开发，在上篇文章中我们采用koa做服务端，那么我们尝试封装一个koa的中间件。

封装

图1

如图1，我们需要做的工作就是把图中红色区域的代码封装成一个中间件，我们把这个中间件代码放在cors.js文件中。

图2

cors请求头需要可以配置，所以参数可以通过中间件传进去。图2中options的每个属性对应每个cors头信息的配置。

图3

我们需要判断一下是否是option请求，因为非简单请求发送的option请求主要是用来判断是否能进行cors跨域并不是真正用来请求数据的，所以这里需要分开处理。

图4

首先处理origin，分为以下几种情况：

• 如果options.origin没有配置或者配置为*，都直接设置*；
• 如果options.origin为字符串，直接设置origin；
• 如果options.origin为数组，把它变成字符串再设置；
• 如果options.origin为正则表达式，并且匹配正确，设置请求头带来的origin；
• 如果options.origin为函数，并且返回true，也设置请求头带来的origin；

图5

图5所示，携带cookie，只要设置options.credentials为true即可。

图6

图6处理cors请求方法配置，如果是数组，就把它转化为字符串。

图7

allowHeaders和ExposeHeaders配置的设置一样，如图7所示。

图8

Access-Control-Max-Age单位是秒，此处判断类型是数字才设置，字符串也是可以的。

图9

因为是option请求，所以在如图8所示位置就可以让其直接返回，此处也可以加一个配置，判断option请求是否需要继续向下处理。

图10

在不是option请求时，我们也需要配置cors信息头。即使是非简单请求的第二个请求，如果不配置浏览器也会报错。

图11

只需要配置origin、credentials和exposedHeaders就可以了。

使用案例如下：

图12

总结

利用中间件可以使这部分逻辑配置化和公共化，使用更加方便。cors跨域方案看似蛮简单的，但是坑很多，如果不亲自踩踩，可能影响不会那么深刻。

喜欢我的文章就关注我吧，有问题可以发表评论，我们一起学习，共同成长！