thinkjs REST API的跨域设置

用thinkjs也有一小段时间了，和其它国产框架同样，起初是处于观望态度。固然我最早的选择也不是thinkjs而是选的express,用到后面发现实现一个能让本身用着比较顺手的博客仍是一件蛮困难或者说是繁琐的事情。远没有本身起初所想的那样简单，再次感叹一切贵在坚持...

express虽然足够简洁，不过想要重头开始实现一个相对完善的博客程序无疑是须要很大工做量的，想到立刻过时的虚拟机，thinkjs这样更加全面和强大的mvc框架变成了我理想的选择，其中的诸多特性(灵活的路由，方便的MVC,完善的数据校验，面向将来的Es6/7支持，简洁的数据库CURD操做等等)足够本身使用了。

-- 。--~啰嗦了，回到正题，因为后台管理界面我选择了先后端分离的模式，并且分红了两块不一样的构建项目（有点折腾，不过我的以为两个搅和在一块儿做为一个项目进行构建会更让我头大哈哈，毕竟如今前端也变得复杂，有本身一套独立的构建工具流），天然也有了跨域的需求，好在官方文档有提供相对完善的配置说明，我用了如下设置：

this.header("Access-Control-Allow-Origin", this.header("origin") || "*"); 

彷佛简单的一句就解决了跨域问题，得益于标准这确实解决了咱们一些跨域场景需求。 上边提到的CORS是一个W3C标准，全称是"跨域资源共享"（Cross-origin resource sharing）

进一步的需求（支持跨域cookie）

跨域的同时我又遇到了须要给客户端cookie，CORS一样能够作到, 能够像下面这样:

this.header('Access-Control-Allow-Credentials',true); // 在服务端设置 

// 客户端一样设置，这里以Jquery为例(约定好规则 😅相似一个愿打一个愿挨)

// 跨域设置cokkie $.ajax({  url: a_cross_domain_url,  xhrFields: {  withCredentials: true } }); 

还能够跨域设置cookie的需求咱们也解决了。

进进一步的需求（支持REST API）

当我觉得一切OK的时候，REST的DELETE和PUT请求却唱起了反调，这是要给好处费吗....由于用到了REST API，仅使用上边的设置还不能实现DELETE及PUT的跨域请求，表示我心里当时是崩溃的，折腾了两天，总算找到了问题所在，起先找的Thinkjs官网文档，有提供例子，不看还好，这一看完全掉坑里了。

Thinkjs官网文档

// 若是是在 REST API，那么能够放在 __call 方法里判断，如： export default class extends think.controller.base { __call(){ let method = this.http.method.toLowerCase(); if(method === "options"){ this.setCorsHeader(); this.end(); return; } this.setCorsHeader(); return super.__call(); } setCorsHeader(){ this.header("Access-Control-Allow-Origin", this.header("origin") || "*"); this.header("Access-Control-Allow-Headers", "x-requested-with"); this.header("Access-Control-Request-Method", "GET,POST,PUT,DELETE"); this.header("Access-Control-Allow-Credentials", "true"); } } 

爬出坑的设置

// 服务端代码 async __before() { this.header("Access-Control-Allow-Origin", this.header("origin") || "*"); this.header("Access-Control-Allow-Headers", "x-requested-with"); this.header("Access-Control-Allow-Methods", "GET,POST,OPTIONS,PUT,DELETE"); this.header('Access-Control-Allow-Credentials',true); let method = this.http.method.toLowerCase(); if(method === "options"){ this.end(); return; } let isLogin = await this.session('userInfo'); if(!isLogin){ this.fail('AUTH_FAILED'); } } 

this.header("Access-Control-Allow-Methods", "GET,POST,OPTIONS,PUT,DELETE");

就是这家伙了，隐藏得比较深，不过本质不坏，就靠它干活。

回顾并梳理

REST请求能够分红两种，一种是简单请求，GET,POST及HEAD都算其中。另外一种就是非简单请求，顾名思意它要复杂一些，按钮w3c规范它会先发一次预请求（Preflighted requests），去询问下服务器我能不能知足要求，知足的话会返回一系列CORS头信息设置，返回请求后客户端一样会验证，这两家伙表示彼此都不信任对方0。0，客户端会受浏览器的同源策略影响，由于相对GET POST HEAD请求，PUT DELETE请求安全性要求会更高些，验证更严格也是理所应当的。其中Orgin会自动被服务端获取，客户端能够不用配置，默认包含在请求头中发送，其它的设置基本都须要两两对应设置。

兼容性

现代浏览器均支持，IE10有完整实现，IE8 9须要经过 XDomainRequest 对象来实现CORS(¬_¬)。

图示

简单请求

cokkie设置

非简单请求(预请求+主请求)

综合

Tips:想要更详细的了解能够查看底下列出的参考文档！不知觉中表示写的太多了点....

参考文档

HTTP访问控制(CORS)