如果我們訪問的資源是不需要授權的，也就是在http請求頭中不包含 authentication 頭那麼以上做法就足夠了。但是如果該資源是需要許可權驗證的，那麼這個時候跨域請求的預檢測 option 請求，由於不會攜帶身份資訊而被拒絕 。瀏覽器會報出401錯誤。
前幾天的文章 spring通過cros協議解決跨域問題 中提到了如何解決跨域問題的基本思路,解決了跨域請求時瀏覽器403錯誤。
response to preflight request doesn't pass access control check:401錯誤資訊如下：no 'access-control-allow-origin' header is present on the requested resource.
origin 'null' is therefore not allowed access.
the response had http status code 403
response for preflight has invalid http status code 401既然知道了問題的原因，答案也就很容易得出： 對需要進行跨域請求的資源（api），當服務端檢測到是 optons 請求時候統統放行，給出http.ok(200)的狀態和必要的響應頭，哪怕它是不帶身份資訊的 。
這個問題既可以通過編寫對應的後端**實現，也可以通過設定伺服器配置檔案實現。也就是如何設定響應頭和返回200狀態碼的辦法了。
shiro中可以在自己實現的身份驗證filter中加入以下**：
@overrideshiro中accesscontrolfilter提供了訪問控制的基礎功能；比如是否允許訪問/當訪問拒絕時如何處理等，也是我們一般自定義許可權驗證時候的乙個父類，我們通過重寫他的 onprehandle 方法判斷是否是 option 請求，如果是則設定相應狀態，（響應頭已經在之前文章中通過filter配置過了）返回false表示該***例項已經處理了，將直接返回即可。protected boolean prehandle(servletrequest servletrequest, servletresponse servletresponse) throws exception
return super.prehandle(request, response);
}
需要修改tomcat的全域性web.xml檔案在 catalina_home/conf 下，加入以下配置。
rewriterule ^(.*)$ $1 [r=200,l]請求時候需要加上 authorization 和 content-type 頭。
iframe跨域問題 跨域的幾種實現方式
一 背景同源策略 同源策略可以理解為瀏覽器的一種安全機制，瀏覽器只允許與本域下的介面進行互動。不同源的客戶端在沒有明確授權的情況下，不能讀寫服務端的資源。什麼是不同源呢 補充點 在出現跨域問題時，瀏覽器究竟在哪一步進行了攔截？客戶端請求時？伺服器不做出響應？還是伺服器響應後瀏覽器拒絕的響應？測試發現...
使用ajax進行前後端通訊時的跨域問題
當頁面位址和服務端通訊位址的ip或埠不同時，就發生了跨域，這時需要服務端允許跨域以後，才能正常訪問服務端。解決方法 在服務端的響應頭中設定 access control allow origin 即可解決這個問題。如果請求頭發生修改並且非同源，就需要申請請求頭跨域。比如上傳的資料型別不是預設的文字型...
nginx實現閘道器解決跨域問題（大型閘道器介面系統）
1 同一網域名稱下 允許 2 同一網域名稱不同資料夾 允許 3 同一網域名稱不同埠號 不允許 4 同一網域名稱不同協議 不允許 5 網域名稱與網域名稱對應的ip位址 不允許 6 主網域名稱相同，子網域名稱不同 不允許 7 不同網域名稱 不允許解決方案 ajax的jsoup可以利用ajax的jsoup...