彻底弄懂跨域问题

38次阅读

共计 5414 个字符,预计需要花费 14 分钟才能阅读完成。

跨域,老生常谈的问题
简述
作为一只前端菜鸟,跨域方面只懂得 JSONP 和 CORS,并未曾深入了解。但随着春招越来越近,就算是菜鸟也要猛振翅膀。近几日仔细研究了跨域问题,写下这篇文章,希望对开发者们有所帮助。在读本文前,希望您对以下知识略有了解。

浏览器同源策略
nodejs
iframe
docker, nginx

我们为何要研究跨域问题
因为浏览器的同源策略规定某域下的客户端在没明确授权的情况下,不能读写另一个域的资源。而在实际开发中,前后端常常是相互分离的,并且前后端的项目部署也常常不在一个服务器内或者在一个服务器的不同端口下。前端想要获取后端的数据,就必须发起请求,如果不错一些处理,就会受到浏览器同源策略的约束。后端可以收到请求并返回数据,但是前端无法收到数据。
多种跨域方法
跨域可以大概分为两种目的

前后端分离时,前端为了获取后端数据而跨域
为不同域下的前端页面通信而跨域

为前后端分离而跨域
Cross Origin Resource Share (CORS)
CORS 是一个跨域资源共享方案,为了解决跨域问题,通过增加一系列请求头和响应头,规范安全地进行跨站数据传输
请求头主要包括

请求头
解释

Origin
Origin 头在跨域请求或预先请求中,标明发起跨域请求的源域名。

Access-Control-Request-Method
Access-Control-Request-Method 头用于表明跨域请求使用的实际 HTTP 方法

Access-Control-Request-Headers
Access-Control-Request-Headers 用于在预先请求时,告知服务器要发起的跨域请求中会携带的请求头信息

响应头主要包括

响应头
解释

Access-Control-Allow-Origin
Access-Control-Allow-Origin 头中携带了服务器端验证后的允许的跨域请求域名,可以是一个具体的域名或是一个 *(表示任意域名)。

Access-Control-Expose-Headers
Access-Control-Expose-Headers 头用于允许返回给跨域请求的响应头列表,在列表中的响应头的内容,才可以被浏览器访问。

Access-Control-Max-Age
Access-Control-Max-Age 用于告知浏览器可以将预先检查请求返回结果缓存的时间,在缓存有效期内,浏览器会使用缓存的预先检查结果判断是否发送跨域请求。

Access-Control-Allow-Methods
Access-Control-Allow-Methods 用于告知浏览器可以在实际发送跨域请求时,可以支持的请求方法,可以是一个具体的方法列表或是一个 *(表示任意方法)。

如何使用

客户端只需按规范设置请求头。
服务端按规范识别并返回对应响应头,或者安装相应插件,修改相应框架配置文件等。具体视服务端所用的语言和框架而定

SpringBoot 设置 CORS 例子
一个 spring boot 项目中关于 CORS 配置的一段代码
HttpServletResponse httpServletResponse = (HttpServletResponse) response;
String temp = request.getHeader(“Origin”);
httpServletResponse.setHeader(“Access-Control-Allow-Origin”, temp);
// 允许的访问方法
httpServletResponse.setHeader(“Access-Control-Allow-Methods”, “POST, GET, PUT, OPTIONS, DELETE, PATCH”);
// Access-Control-Max-Age 用于 CORS 相关配置的缓存
httpServletResponse.setHeader(“Access-Control-Max-Age”, “3600”);
httpServletResponse.setHeader(“Access-Control-Allow-Headers”,
“Origin, X-Requested-With, Content-Type, Accept,token”);
httpServletResponse.setHeader(“Access-Control-Allow-Credentials”, “true”);
JSONP 跨域
jsonp 的原理就是借助 HTML 中的 <script> 标签可以跨域引入资源。所以动态创建一个 <srcipt> 标签,src 为目的接口 + get 数据包 + 处理数据的函数名。后台收到 GET 请求后解析并返回函数名 (数据) 给前端,前端 <script> 标签动态执行处理函数观察下面代码

前端代码
<!DOCTYPE html>
<html lang=”en”>
<head>
<meta charset=”UTF-8″>
<title>Title</title>
</head>
<body>
<script>
var script = document.createElement(‘script’);
script.type = ‘text/javascript’;

// 传参并指定回调执行函数为 getData
script.src = ‘http://localhost:8080/users?username=xbc&callback=handleData’;
document.body.appendChild(script);
// 回调执行函数
function handleData(res) {
data = JSON.stringify(res)
console.log(data);
}
</script>
</body>
</html>

后端代码(nodejs)
var querystring = require(‘querystring’);
var http = require(‘http’);
var server = http.createServer();

server.on(‘request’, function(req, res) {
var params = querystring.parse(req.url.split(‘?’)[1]);
var fn = params.callback;

// jsonp 返回设置
res.writeHead(200, { ‘Content-Type’: ‘text/javascript’});
var data = {
user: ‘xbc’,
password: ‘123456’
}
res.write(fn + ‘(‘ + JSON.stringify(data) + ‘)’);

res.end();
});

server.listen(‘8080’);
console.log(‘Server is running at port 8080…’);

在该例子中,前台收到的 res 是这样的
前端页面是这样的
注意
JSONP 既是利用了 <srcipt>,那么就只能支持 GET 请求。其他请求无法实现
nginx 反向代理实现跨域
思路
既然浏览器有同源策略限制,那我们把前端项目和前端要请求的 api 接口地址放在同源下不就可以了?再结合 web 服务器提供的反向代理,便可以在前端和后端都不做配置的情况下解决跨域问题。
以 nginx 为例

后端真实后台地址:http://xxx.xxx.xxx.xxx:8085 后台地址使用 tomcat 部署的 spring boot 项目 名为 gsms_test

nginx 服务器地址: http://xxx.xxx.xxx.xxx:8082

tomcat 和 nginx 都是用 docker 架设的,做了端口转发

nginx /etc/nginx/conf.d/default.conf 配置代码如下
server {
listen 80;
server_name localhost;

#charset koi8-r;
#access_log /var/log/nginx/host.access.log main;

location / {
root /usr/share/nginx/html/dist; # 前端项目路径
index index.html index.htm;
autoindex on;
autoindex_exact_size on;
autoindex_localtime on;
}

location /gsms_test/ {
proxy_pass 后端真实地址;
}

#error_page 404 /404.html;

# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}

# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ \.php$ {
# proxy_pass http://127.0.0.1;
#}

# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
#location ~ \.php$ {
# root html;
# fastcgi_pass 127.0.0.1:9000;
# fastcgi_index index.php;
# fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
# include fastcgi_params;
#}

# deny access to .htaccess files, if Apache’s document root
# concurs with nginx’s one
#
#location ~ /\.ht {
# deny all;
#}
}

不同域下页面通信而跨域
window.name + iframe 跨域
window.name 是浏览器中一个窗口所共享的数据,在不同的页面(甚至不同域名)加载后依旧存在(如果没修改则值不会变化),并且可以支持非常长的 name 值(2MB)。比如 a 域的某页面想获取 b 域某页面的数据,可以在 b 域中修改 window.name 值,a 域切换到 b 域再切回来即可得到 b 域的 window.name 值。可是我们在开发中肯定不想页面切来切去,所以就要结合 iframe 来实现。
示例 (以 thinkjs 实现)

a 域代码如下
<!DOCTYPE html>
<html>
<head>
<meta charset=”UTF-8″>
<title>A 域 </title>
</head>
<body>
<h1>server A</h1>
<script type=”text/javascript”>
function getData() {
var iframe = document.getElementById(‘proxy’);
iframe.onload = function () {
var name = iframe.contentWindow.name; // 获取 iframe 窗口里的 window.name 值
console.log(name)
}
// 由于 iframe 信息传递也受同源策略限制,所以在 window.name 被 B 域修改后,将 iframe 转回 A 域下。以便获取 iframe 的 window.name 值
iframe.src = ‘http://127.0.0.1:8360/sub.html’
}
</script>
<iframe id=”proxy” src=”http://127.0.0.1:8361/index.html” style=”width: 100%” onload=”getData()”> </iframe>
</body>
</html>

b 域代码
<!DOCTYPE html>
<html>
<head>
<meta charset=”UTF-8″>
<title>New ThinkJS Application</title>
</head>
<body>
<h1>server 2</h1>
<script type=”text/javascript”>
window.name = ‘user: xbc’;
</script>
</body>
</html>

注意
由于受同源策略限制,父页面获取跨域的 iframe 页面的信息不全,所以要在 iframe 的 window.name 被 B 域修改后,转为 A 域下的任一页面(该一面不得修改 window.name),在进行获取。
代理页面 + iframe 实现跨域访问
由于 iframe 与父页面相互访问也受同源策略限制,所以要借助一代理页面实现跨域。

个人认为有些麻烦,若有兴趣请看前端如何用代理页面解决 iframe 跨域访问的问题?
总结
以上几种皆是本人用过或测试过的跨域方法,还有 postMessage,WebSocket 等跨域方法由于从未接触不做说明。在项目中具体使用那些方法还需具体考录各种问题

情况
方法

只有 GET 请求
JSONP

对兼容性及浏览器版本无要求
CROS

对兼容性及浏览器版本有要求
iframe 或 服务器反向代理

本文参考

经验 跨域方案
CORS——跨域请求那些事儿
前端如何用代理页面解决 iframe 跨域访问的问题?
前端常见的跨域解决方案(全)
CORS 与服务器反向代理的优劣对比
图解正向代理、反向代理、透明代理

谢谢
本文如有错误,欢迎留言私信讨论指出

正文完
 0