之前討論過，在解決post跨域請求時，採用iframe+本域**頁的形式，相容性（當然是包括ie6啦）是最好的。上次提到，**頁面的作用是：執行本域下的**函式。就是這個原因，給xss帶來了便利。詳細說明，請參考乙個跨域請求的xss漏洞
上次也提到，解決這個問題的根本在於杜絕不合法的函式在頁面內執行。上次透了一下懶，對函式名就行了包含匹配。過程如下：
/*** callback的值為：namespace.function，prefix123456
*/var filter = [
'namespace',
'prefix'
];//驗證函式，返回true時，return
var validatecallback = function (callback)
} return flag;
}if(validatecallback(callback))
從上面的**可以看出，只有我的白名單的函式才能通過並執行。並且namespace是我定義的命名空間，我只要保證我的函式不會造成xss就可以了吧。可是我太天真了，沒想到還有這麼個情況：
這個時候，很輕鬆的就在a.com下，執行了第三方的js檔案，想想都是一件可怕的事情。那為什麼它能執行呢？
此時的namespace就是iframe的window，我們可以想象document.namespace是什麼結果
一般情況下，a.com的頁面上都會引用jquery或者其他的js庫，很方便的呼叫乙個方法執行乙個ajax請求乙個js檔案，並執行
更重要的是，它可以操作window上所有的方法
……那怎麼解決呢？我最初想到的辦法是：不改變現在白名單的情況下，增加網域名稱白名單，只有在網域名稱白名單裡的網域名稱才能執行。與此同時，遇到的乙個問題是，我無法在proxy中，判斷對我請求的網域名稱是否合法。我最初想到的兩種獲得網域名稱的方式是：document.referrer和parent.document.domain，下面我簡單說明這兩種形式為什麼能判斷。
無論通過那種方式限制，最重要的一點不能忘記：合法的請求，不能被限制。如果第三方採用iframe引用的話，猶豫同源策略，parent.document.domain會丟擲異常，無法進行判斷；至於document.rederrer的問題在於，如果巢狀多層iframe的話，我的reffer是正常的，其實還是非法的引用。
既然這個也被否定了，我到底怎麼辦呢？難道真的沒辦法防住這個嗎？我又重新思考了一遍，為什麼會出現這個xss漏洞呢？最主要的原因還是這個函式名。現在所做的沒有對函式名進行嚴格控制，只是在判斷包含關係。所以接下來要做的就是限制死函式名，只能是我的filter裡的，可以通過恒等或者是正則匹配完成。
/*** callback的值為：namespace.function，prefix123456,prefix1231321
*/var filter = [
'namespace.function',
/^prefix\d$/
];//驗證函式，返回true時，return
var validatecallback = function (callback) {
var flag = true;
for(var i=0;i通過上面的這種形式，暫時解決了這個xss漏洞。當然這個問題還是乙個長期的問題，還是需要長期跟進，遇到問題，隨時解決。
Ajax跨域請求保證同乙個session的
我們知道，根據瀏覽器的保護規則，跨域的時候我們建立的sessionid是不會被瀏覽器儲存下來的，這樣，當我們在進行跨域訪問的時候，我們的sessionid就不會被儲存下來，也就是說，每一次的請求，伺服器就會以為是乙個新的人，而不是同乙個人，為了解決這樣的辦法，下面這種方法可以解決這種跨域的辦法。我們...
解決乙個跨域問題
因為我用flask框架 構建了乙個web 服務端，所以我建立乙個請求介面，這個介面 作用就是請求對方的 m3u8 鏈結，然後將響應內容返回給使用者 並且在這個函式中可以實現很多突破防盜煉的功能，例如 檢測請求頭中的referer字段。可以這樣寫 瀏覽器中支援很多協議，我相信都見到過這種 二進位制經過...
Ajax跨域請求另乙個tomcat服務下介面的問題
tomcat7 下cors 跨域資源共享 的配置 cors介紹 它在維基百科上的定義是 跨域資源共享 cors 是一種網路瀏覽器的技術規範，它為web伺服器定義了一種方式，允許網頁從不同的域訪問其資源。而這種訪問是被同源策略所禁止的。cors系統定義了一種瀏覽器和伺服器互動的方式來確定是否允許跨域請...