現有需求如下：
login.nx.com
是nx.com
的二級網域名稱，
login.nx.com
是nx.com
的登入中心應用，現在有兩個拍馬屁的**
(sb.com
、sx.com)
想跟nx.com
共享登入，分享一下
nx.com
的使用者資源，現在的整合登入的目標是
: 任何一家**登入後，到其他**後都不需要再重新登入，姑且叫做良民通行證吧，
(souhu
人家也是這麼叫的)
我們都知道，要共享登入，一般情況下是需要共享應用
session
中的資訊的，而
session
儲存一般都是只在單台伺服器的記憶體中的，其他伺服器上的應用需要共享只有通過複製的方式，這是效率低下的，可以進行
session改造,
這裡不具體討論這個問題，可以參考《sna session剖析》
。通過上面一篇文章我們知道，登入相關資訊可以儲存在服務端，也可以儲存在客戶端，要和其他站點共享這些資訊，就需要解決如何在所有站點下同步這些資訊的問題，而解決同步的關鍵又在要解決跨域問題，以服務端儲存為例：
客戶端cookie
中只有sessionid
，登入相關資訊全部在服務端，通過
sessionid
在服務端即可獲取登入資訊，可以這麼理解，只要
sb.com
、sx.com
、nx.com
具有相同的
sessionid
，那麼在服務端他們就可以根據相同
sessionid
拿到登入狀態，也就共享了登入資訊，基於這個思路，解決方案有如下兩個，各有優缺點：
1、 瀏覽器訪問任何乙個未登入**都跳轉到
login.nx.com
登入中心進行登入，登入成功後設定登入狀態，並設定
cookie
儲存sessionid
，其中domain=.nx.com,
此時,nx.com
包括其子網域名稱都能成功獲取到
sessionid
，同時返回給客戶端其他需要共享登入的網域名稱列表，假設如下
(這裡除了使用
script
，其實ajax
相關的技術都可以,例如
iframe
、img, xhr,
另外注意下
p3p的問題)：
這裡訪問
/pass
目的只有乙個，就是將
sessioinid
給相應的網域名稱，然後
/pass
接收到sessionid
後寫入到自己網域名稱下
cookie
中，這樣
sx.com
、sb.com
網域名稱下都有了這個
sessionid
，好，cookie
設定大功告成，然後該頁面再
redirect
到其他應該去的頁面。只要在這幾個網域名稱下，就不需要再重新登入。
優點：登入處統一設定登入相關
cookie
，集中管理，
除了第一次登入以外其他時候個系統各自為政，登入時統一重新建立
sessionid
，登出時如果
session
儲存在服務端，則直接清除服務端即可，如果儲存在客戶端，則跟登入時一樣，分別請求登出即可。
缺點：但是登入時間會有點長，如果支援網域名稱太多，這個估計有點鬱悶了，不過支援過
4-5個網域名稱問題不大，如果
session
儲存在客戶端，則登出時間也可能會稍長。 2、
瀏覽器訪問任何乙個未登入**（例如
sx.com
）都跳轉到
login.nx.com
登入中心進行登入，登入成功後設定登入狀態，並設定
cookie
儲存sessionid
，其中domain=.nx.com,
此時,nx.com
包括其子網域名稱都能成功獲取到
sessionid
，然後帶著
sessionid
引數跳轉到
分析出sessionid
後進行儲存，然後跳轉到
目標頁，此時這個頁面是登入狀態的。此時如果訪問
時，sb.com
會先檢查是否存在
sessionid,
如果不存在，則
302跳轉請求
，由於之前
login.nx.com
已經登入，此時的請求會將該網域名稱下的
cookie
中sessionid
帶到伺服器，
login.nx.com
獲取到sessionid
後，組裝成
http://sb.com/pass?sessionid=123456&redirect_url=,這個過程，與
sx.com
處理過程一致，如此就完成了登入，如果存在
sessionid
則不需要去登入中心拿
sessionid了。
優點：登入時間完全縮短，不論多少個應用都不會影響登入。
缺點：未登入也需要建立
sessionid,
因為如果沒有
sessionid
，則每個需要登入資訊的頁面
(那種登入與否都可以看的頁面
)都要去
login.nx.com
去訪問一次，這樣再
nx的也受不了這樣折騰啊，
另外，由於未登入時
sessionid
已經生成，所以使用者登入後這裡會重複利用
sessionid
，除非瀏覽器關閉。另外登出時由於要清除所有網域名稱下的
sessionid
，可能速度會有點慢，當然也可以不清除，那麼在瀏覽器關閉之前，這個
sessionid
會被重複利用，可能稍微有點安全隱患。
注：網上流傳著一種在兩個網域名稱下共享
cookie
的方案，即
a.com
，b.com
如果需要共享
cookie
，則在訪問
a.com
將cookie
設定成cookie.setdomain(『.b.com』)
，這樣b.com
就可以訪問這個
cookie
，a.com
由於是生成這個
cookie
的應用，因此也可以訪問，這就完成了共享，其實這是錯誤的，在
a.com
的網域名稱下完全不可能訪問乙個
domain=.b.com
的cookie
，既然不能基本的儲存都不可能，何來共享？各位不服氣的看官可以自己回去服務端或者
js設定一下，看設定成
domain=.126.com
後的cookie
是否儲存下來了，，然後再回來批判我，我自會刪除這段東東。
多網域名稱 跨域 登入資訊共享解決方案亂彈
現有需求如下 login.nx.com 是 nx.com 的二級網域名稱，login.nx.com 是 nx.com 的登入中心應用，現在有兩個拍馬屁的 sb.com sx.com 想跟 nx.com 共享登入，分享一下 nx.com 的使用者資源，現在的整合登入的目標是 任何一家 登入後，到其他 ...
跨域解決方案
因為瀏覽器出於安全考慮，有同源策略。也就是說，如果協議 網域名稱或者埠有乙個不同就是跨域，ajax 請求會失敗。那麼是出於什麼安全考慮才會引入這種機制呢？其實主要是用來防止 csrf 攻擊的。簡單點說，csrf 攻擊是利用使用者的登入態發起惡意請求。也就是說，沒有同源策略的情況下，a 可以被任意其他...
跨域解決方案
瀏覽器端的同源策略 如果兩個頁面的協議,埠和網域名稱中的其中任意乙個不相同,它們就是不同源的,瀏覽器會限制他們之間的資源互動 跨域 跨域的安全限制只針對瀏覽器,伺服器是沒有跨域的安全限制的 原理 由於伺服器沒有跨域限制，所以在需要跨域訪問時，在中間設定乙個中間層 舉例 192.168.10.1 80...