日常在前端开发工作中跨域问题是很正常是的事情，因为稍大一些的项目你总不能实时的保存到服务器然后线上预览开发，影响线上环境又不方便开发。
其实跨域问题主要是存在开发环境中，生成环境已经布置到服务器上了不存在跨域问题。
常用的有几种方式解决跨域的问题。
1、用构建工具，好多团队也是用这种方式解决的
module.exports = {
//...
devServer: {
proxy: {
'/api': {
target: 'http://www.baidu.com/',
pathRewrite: {'^/api' : ''},
changeOrigin: true, // target是域名的话，需要这个参数，
},
'/api2': {
.....
}
}
}
};
这段代码的配置 捕获api标识 比如http://localhost:8080/api/users 前端发起这个请求
里面包含api字段 就会被捕获到 然后执行配置
target
代理的API地址 可以理解成要替换更改成的域名
可以是域名也可以是ip 是域名下面changeOrigin要填写成true
pathRewrite
路径重写 比如现在这个例子 前端访问http://localhost:8080/api/users 这个接口
其实会转化成 http://www.baidu.com/users
changeOrigin
这个参数可以让target参数是域名
2、jsonp前端跨域请求
说jsonp 之前先来说下了为什么会出现跨域请求，好端端的很欢快的敲得代码，很正常的ajax请求为什么会出现跨域请求，是因为同源策略。
同源策略是浏览器的一个安全功能，不同源的客户端脚本在没有明确授权的情况下，不能读写对方资源。
地址里面的协议、域名和端口号均相同则属于同源。
三点 协议（http和https）、域名、端口全部相同可访问，其中有一项不同就会受到同源策略的影响，也能想的通啦，你的接口谁都能使用肯定不安全，这也是为什么项目实时保存到服务器上预览开发不受跨域影响的原因（都放服务器上了，自己访问自己肯定是同源咯）。
但再思考一个问题，jq cnd这大家都经常用吧，cnd不在咱们的本地也不在服务器上为啥能访问内，img标签使用网络图片，图片也是在别人的服务器上为啥能用内，
因为img、iframe 、script 及其他多媒体标签不受同源策略的影响，嘿是不是漏出了邪恶的笑容，程序员这个行业啊一旦出现什么什么不受影响那就是告诉你，这里可以搞事。
jsonp也就是用的这个原理 动态创建加载一个 script标签，script标签的src就是后台的接口地址然后和后台预定好一个回调函数字段，一般就是callback，最后再确定下来要传给后台的字段
把这些拼接起来
例如http://www.a.com/test/index.php 这是接口 callback 对应的回调函数是foo 数据是 name = 'tianyu'
拼接的结果 http://www.a.com/test/index.php?callback=foo&name='tianyu'
把拼接结果放到动态创建的script上 这个scriptt标签就会自动加载src路径后台就能获取到请求
php代码
$jsonData = getDataAsJson($_GET['symbol']); //组织好发送字段
echo $_GET['callback'] . '(' . $jsonData . ');'; //拼接参数
注意看这里的后台代码，前端script请求的src是个.php文件 后台接受到了后先是拼接返回的数据，然后具体返回的是 函数名(拼接的参数)，这是前端拿到的script的内容就是 foo(后台传递进来的参数)
前端的foo(data) 函数中就会被调用并且data就是 后台拼接好的字段给你。
这里如果没有立即理解就再仔细想想，原理不难就是通过script标签的形式发起一个请求，后台接受到了请求后组装信息，信息组装好前端加载到的就是一个js文件，js里有你定义好的函数以及需要的数据，并且浏览器默认执行新加载的js你也就顺理成章的完成了这次请求，拿到了想要的数据。
这就是jsonp的原理 利用部分标签不受同源策略的影响去加载接口 当然都说到这一步了你肯定也能想到jsonp只支持get请求不接受post jquery也是这样 jq只是更好的封装了下肯定不能更改这jsonp的原理
$.ajax({
url: 'http://192.168.1.114/yii/demos/test.php', //不同的域
type: 'GET', // jsonp模式只有GET 是合法的
data: {
'action': 'aaron'
},
dataType: 'jsonp', // 数据类型
jsonp: 'callback', // 指定回调函数名，与服务器端接收的一致，并回传回来
})
jq只是帮助了你更好的封装 内部做好一些清除缓存的机制（就是每次请求callback对应的回调函数不一样）
这就是jsonp的内部原理机制。
3、再说一种跨域请求的方式 后端解决的办法 专业名叫 CORS
前端不用做什么跨域方面的准备 主要工作是在后端这一块
不过在这里也会简单的介绍一下 xhr（XMLHttpRequest）
后端这里我就拿node举例子
先说xhr 毕竟前端发起请求后端接受 先说发起这一块
xhr其实就是我们常用到的ajax， jq的$.ajax 底层封装的就是xhr
现在网上也有fetch （新一代的ajax api），也看了一些文章 ajax已死 fetch永生什么的 首先必须承认的是文章写得非常好 fetch 好处也是非常多
语法简洁，更加语义化
基于标准 Promise 实现，支持 async/await
可以链式调用
相对于xhr 没有回调地狱 符合关注分离原则
等等 不多说
但我感觉xhr 用的也挺舒服 至于回调地狱也可以用封装的手法外层加上Promise而且兼容强，主流浏览器都支持 现在网上好多fetch的js封装都要有判断 当前浏览器是否支持fetch 不支持还是要xhr
这里不多说本文不讨论fetch和xhr谁好谁坏，个人用的舒服就行，本文还是用xhr说前端请求这一块。
//第一步创建xhr
let xhr = new XMLHttpRequest();
//第二步 定义xhr 的状态返回码 用于判断请求是否成功
xhr.onreadystatechange = function(){
if(xhr.readyState == 4){
if(xhr.status >= 200 && xhr.status < 300){
try {
let res = JSON.parse(xhr.responseText);
callback(res)
} catch (e) {
let msg = "请求数据失败,返回的不是JSON";
console.log(msg,e);
errorCallback && errorCallback({
retcode: xhr.status,
msg: msg
});
}
}
}
}
//其他的method 就不演示了 每个项目有自己的规则例如get写到url上 post写到data里或者其他的url上加token之类的
//这些每个项目都有不同需要和后端商定好自定义写逻辑就行
//第三步 初始化http请求参数
xhr.open(method, url, true); //请求方式 请求地址 是否异步
//第四部 发送http请求
xhr.send();
暂时先这个样子简易的ajax请求就发起了
然后就很顺利的就能看到浏览器报错了。
image.png
错误信息基本是长这样子的大概意思是请求头检测没有通过
this.header("Access-Control-Allow-Origin", this.header("origin") || "*");
（这个只是参考 node的写法 其他的根据不同语言写法有差异）
很简单加上这一句就能解决请求跨域问题
这个是用来指定那些客户端的域名可以访问该资源 填写通配符 * 就是全部或是填写一个完整的url
已经可以愉快的发起请求了
不过这只是最简单的请求方式 忽然有一天后端人员找你 需要加上在HTTP的头部增加些信息，可能是增加一些安全类的签名或是用户登录的token 或是多样性请求方式等等啦就会发现又出问题了，
image.png
明明发送的是get请求但这里显示是 OPTIONS
其实并不是你的请求变成了OPTIONS 而是多发送了一个请求你写好的真正的请求还没有发起。
OPTIONS这次请求有人称为"预检"请求 也有人叫他 "嗅探"请求
浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。
那什么情况下回出现这次OPTIONS请求呢？
复杂请求时 复杂请求 和 简单请求的区别在于简答请求只有简单的get/head/post请求，且不能自定义http的headers，一旦你发送的是put、delete之类或是增加了headers就会变成复杂请求也就会多发少一次OPTIONS请求，这是浏览器默认的无法阻止的。
解决办法也很简单没有想得这么复杂，同样也是后台同学帮忙解决。
让默认第一次发送的OPTIONS请求通过即可解决，OPTIONS接到了请求成功的通知后会立即发送真正的请求。
this.header("Access-Control-Allow-Origin", this.header("origin") || "*");
//那些域名请求可以通过
this.header("Access-Control-Allow-Methods", "GET,POST,OPTIONS,PUT,DELETE");
//服务器支持的请求的方法
this.header("Access-Control-Allow-Headers", "content-type,x-requested-with,x-token");
//服务器支持的所有头信息字段
this.header('Access-Control-Allow-Credentials',true);
//允许客户端携带验证信息，例如 cookie 之类的
if(this.method == 'OPTIONS'){
return this.success({},'让你通过，正式请求赶紧来吧');
//不处理 OPTIONS请求 让其通过就行
}
一样的上面这些是node 的写法，其他语言会略有不同但基本字段是这些设置上以后就可以完美解决跨域问题
日常开发时第三种用的方式比较多一些，毕竟设置起来不是很困难并且能有效的解决问题。
基本的跨域请求我在项目中用到也就是这些。
然后咱们再来说说和请求关系的cookie以及session，下一篇文章写。
网友评论