为什么要研究跨域问题

发布时间:2020-12-05 11:12:50 作者:小新
来源:亿速云 阅读:194

这篇文章将为大家详细讲解有关为什么要研究跨域问题,小编觉得挺实用的,因此分享给大家做个参考,希望大家阅读完这篇文章后可以有所收获。

跨域,老生常谈的问题

简述

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

浏览器同源策略

nodejs

iframe

docker, nginx

我们为何要研究跨域问题

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

多种跨域方法

跨域可以大概分为两种目的

前后端分离时,前端为了获取后端数据而跨域

为不同域下的前端页面通信而跨域

为前后端分离而跨域

Cross Origin Resource Share (CORS)

CORS是一个跨域资源共享方案,为了解决跨域问题,通过增加一系列请求头和响应头,规范安全地进行跨站数据传输

请求头主要包括

请求头解释
OriginOrigin头在跨域请求或预先请求中,标明发起跨域请求的源域名。
Access-Control-Request-MethodAccess-Control-Request-Method头用于表明跨域请求使用的实际HTTP方法
Access-Control-Request-HeadersAccess-Control-Request-Headers用于在预先请求时,告知服务器要发起的跨域请求中会携带的请求头信息

响应头主要包括

响应头解释
Access-Control-Allow-OriginAccess-Control-Allow-Origin头中携带了服务器端验证后的允许的跨域请求域名,可以是一个具体的域名或是一个*(表示任意域名)。
Access-Control-Expose-HeadersAccess-Control-Expose-Headers头用于允许返回给跨域请求的响应头列表,在列表中的响应头的内容,才可以被浏览器访问。
Access-Control-Max-AgeAccess-Control-Max-Age用于告知浏览器可以将预先检查请求返回结果缓存的时间,在缓存有效期内,浏览器会使用缓存的预先检查结果判断是否发送跨域请求。
Access-Control-Allow-MethodsAccess-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架设的,做了端口转发

使用条件:开发环境为linux系统

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;
        proxy_pass http://localhost:8001/; # 前端本机地址,实现自动更新
        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>
<h2>server A</h2>
<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>
  <h2>server 2</h2>
<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
对兼容性及浏览器版本无要求CORS
对兼容性及浏览器版本有要求iframe 或 服务器反向代理(linux 环境下开发)

关于为什么要研究跨域问题就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。

推荐阅读:
  1. Nginx 跨域问题
  2. Laravel - php artisan 研究

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

跨域

上一篇:如何使用JavaScript打开链接

下一篇:es6字符串中新增知识有哪些

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》