摘要：瀏覽器同源策略我們?yōu)楹我芯靠缬騿栴}因?yàn)闉g覽器的同源策略規(guī)定某域下的客戶端在沒明確授權(quán)的情況下，不能讀寫另一個(gè)域的資源。

作為一只前端菜鳥，跨域方面只懂得JSONP和CORS，并未曾深入了解。但隨著春招越來(lái)越近，就算是菜鳥也要猛振翅膀。近幾日仔細(xì)研究了跨域問題，寫下這篇文章，希望對(duì)開發(fā)者們有所幫助。在讀本文前，希望您對(duì)以下知識(shí)略有了解。

瀏覽器同源策略

nodejs

iframe

docker, nginx

因?yàn)闉g覽器的同源策略規(guī)定某域下的客戶端在沒明確授權(quán)的情況下，不能讀寫另一個(gè)域的資源。而在實(shí)際開發(fā)中，前后端常常是相互分離的，并且前后端的項(xiàng)目部署也常常不在一個(gè)服務(wù)器內(nèi)或者在一個(gè)服務(wù)器的不同端口下。前端想要獲取后端的數(shù)據(jù)，就必須發(fā)起請(qǐng)求，如果不做一些處理，就會(huì)受到瀏覽器同源策略的約束。后端可以收到請(qǐng)求并返回?cái)?shù)據(jù)，但是前端無(wú)法收到數(shù)據(jù)。

之所以有同源策略，其中一個(gè)重要原因就是對(duì)cookie的保護(hù)。cookie 中存著sessionID 。黑客一旦獲取了sessionID，并且在有效期內(nèi)，就可以登錄。當(dāng)我們?cè)L問了一個(gè)惡意網(wǎng)站 如果沒有同源策略 那么這個(gè)網(wǎng)站就能通過js 訪問document.cookie 得到用戶關(guān)于的各個(gè)網(wǎng)站的sessionID 其中可能有銀行網(wǎng)站 等等。通過已經(jīng)建立好的session連接進(jìn)行攻擊，比如CSRF攻擊。
這里需要服務(wù)端配合再舉個(gè)例子，現(xiàn)在我扮演壞人 我通過一個(gè)iframe 加載某寶的登錄頁(yè)面 等傻傻的用戶登錄我的網(wǎng)站的時(shí)候 我就把這個(gè)頁(yè)面彈出 用戶一看 阿里唉大公司 肯定安全 就屁顛屁顛的輸入了密碼 注意 如果沒有同源策略 我這個(gè)惡意網(wǎng)站就能通過dom操作獲取到用戶輸入的值 從而控制該賬戶所以同源策略是絕對(duì)必要的.
還有需要注意的是同源策略無(wú)法完全防御CSRF。

跨域可以大概分為兩種目的

前后端分離時(shí)，前端為了獲取后端數(shù)據(jù)而跨域

為不同域下的前端頁(yè)面通信而跨域

CORS是一個(gè)跨域資源共享方案，為了解決跨域問題，通過增加一系列請(qǐng)求頭和響應(yīng)頭，規(guī)范安全地進(jìn)行跨站數(shù)據(jù)傳輸

客戶端只需按規(guī)范設(shè)置請(qǐng)求頭。

服務(wù)端按規(guī)范識(shí)別并返回對(duì)應(yīng)響應(yīng)頭，或者安裝相應(yīng)插件，修改相應(yīng)框架配置文件等。具體視服務(wù)端所用的語(yǔ)言和框架而定

一個(gè)spring boot項(xiàng)目中關(guān)于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 相關(guān)配置的緩存
        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的原理就是借助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返回設(shè)置
    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...");

在該例子中，前臺(tái)收到的res是這樣的

前端頁(yè)面是這樣的

JSONP既是利用了，那么就只能支持GET請(qǐng)求。其他請(qǐng)求無(wú)法實(shí)現(xiàn)

既然瀏覽器有同源策略限制，那我們把前端項(xiàng)目和前端要請(qǐng)求的api接口地址放在同源下不就可以了？再結(jié)合web服務(wù)器提供的反向代理，便可以在前端和后端都不做配置的情況下解決跨域問題。

后端真實(shí)后臺(tái)地址：http://xxx.xxx.xxx.xxx:8085 后臺(tái)地址使用tomcat部署的spring boot項(xiàng)目 名為gsms_test

nginx服務(wù)器地址: http://xxx.xxx.xxx.xxx:8082

tomcat和nginx都是用docker架設(shè)的，做了端口轉(zhuǎn)發(fā)

使用條件：開發(fā)環(huán)境為linux系統(tǒng)

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; # 前端項(xiàng)目路徑
        # index  index.html index.htm;
        proxy_pass http://localhost:8001/; # 前端本機(jī)地址，實(shí)現(xiàn)自動(dòng)更新
        autoindex on;
        autoindex_exact_size on;
        autoindex_localtime on;
    }

    location /gsms_test/ {
        proxy_pass 后端真實(shí)地址;
    }

    

    #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是瀏覽器中一個(gè)窗口所共享的數(shù)據(jù)，在不同的頁(yè)面（甚至不同域名）加載后依舊存在（如果沒修改則值不會(huì)變化），并且可以支持非常長(zhǎng)的 name 值（2MB）。比如 a域的某頁(yè)面想獲取b域某頁(yè)面的數(shù)據(jù)，可以在b域中修改window.name值，a域切換到b域再切回來(lái)即可得到b域的window.name值?？墒俏覀?cè)陂_發(fā)中肯定不想頁(yè)面切來(lái)切去，所以就要結(jié)合iframe來(lái)實(shí)現(xiàn)。

a 域代碼如下

server A

b 域代碼

  
server 2

由于受同源策略限制，父頁(yè)面獲取跨域的iframe頁(yè)面的信息不全，所以要在iframe的window.name被B域修改后，轉(zhuǎn)為A域下的任一頁(yè)面(該一面不得修改window.name)，在進(jìn)行獲取。

由于iframe與父頁(yè)面相互訪問也受同源策略限制，所以要借助一代理頁(yè)面實(shí)現(xiàn)跨域。

個(gè)人認(rèn)為有些麻煩，若有興趣請(qǐng)看前端如何用代理頁(yè)面解決iframe跨域訪問的問題？

以上幾種皆是本人用過或測(cè)試過的跨域方法，還有postMessage，WebSocket等跨域方法由于從未接觸不做說明。在項(xiàng)目中具體使用那些方法還需具體考慮各種問題

經(jīng)驗(yàn) 跨域方案

CORS——跨域請(qǐng)求那些事兒

前端如何用代理頁(yè)面解決iframe跨域訪問的問題？

前端常見的跨域解決方案(全)

CORS與服務(wù)器反向代理的優(yōu)劣對(duì)比

圖解正向代理、反向代理、透明代理

本文如有錯(cuò)誤，歡迎指出
本人郵箱 [email protected]