背景：
目前公司有兩個後臺系統，後臺a和後臺b，登錄會話是通過cookie建立的。現在需要在不經過大改造的情況下，做成看起來像是一個系統
解決思路：
將後臺b的網頁嵌入後臺a中，後臺b準備一個接口1（入參是用戶名，輸出是該用戶名所屬角色所擁有的菜單），後臺a拿到菜單後將菜單它的左側菜單中，在點擊菜單之前，請求接口2（入參是用戶名，實現的功能是爲該用戶種下cookie，這樣就是登錄了，response中會攜帶set-cookie，瀏覽器在收到後會將cookie種到接口2所屬的域名下，這樣當點擊後臺b的菜單時就可以直接打開了），接口2的請求方式要通過script標籤包住，例如<script src="接口2的url"></script>，這種方式不是XHR的請求方式，所以也就避開了跨域安全問題
引申：
跨域：只要協議、路徑、端口任意一個不一樣就是跨域
發生跨域安全問題的三要素：
1.瀏覽器檢查不允許跨域請求
2.本身請求屬於跨域請求
3.請求方式是XHR
只有具備了上面的三個要素纔會發生跨域安全問題，所以當發生跨域安全問題，三者只要解決一個問題也就解決了
解決“瀏覽器檢查不允許跨域請求”：
這種方式是從客戶端的瀏覽器着手，所以不實用
解決“請求方式是XHR”：
類似於jsonp方式，這種方式是將原本屬於與XHR的請求方式更改爲其它請求方式
解決“本身請求屬於跨域請求”：
這個解決方式有兩個方向：1.被調用方解決跨域 2.調用方解決跨域
被調用方解決跨域：使被調用方允許跨域（在代碼層中的header中添加或者在nginx的服務器配置文件中添加）
調用方解決跨域：調用方使用代理，因爲「跨域」的限制 僅僅在瀏覽器和服務器之間。我們不能強制遠程服務器都允許「跨域」請求，所以我們能做的就是不要使用瀏覽器發送請求。所以在前端開發中，一種常見的規避跨域的方法就是：把 ajax 請求發送到你的本地開發服務器，然後本地開發服務器再把 ajax 請求轉發到遠端去，從網絡拓撲上看本地開發服務器起着「反向代理」的作用。本地服務器和遠端服務器是「服務器和服務器間的通信」，就不存在跨域問題了