淘寶、京東跨域共享會話的分析與總結

前言：你是否好奇在登陸了taobao.com，而後tmall.com也有了會話信息呢？

OK，下面咱們來解密吧：

首先，在login.taobao.com登陸淘寶帳號

這裏看不到含有tmall.com的請求

淘寶登陸完畢後，新開tab鍵入tmall.com

這是一個普通的200請求

咱們發現，vip.tmall.com請求了屢次，響應碼也不一樣，剛開始是302跳轉，後面是普通的200請求

這個302跳轉到https://login.taobao.com/jump下

這是200響應輸出內容

跳轉到login再跳轉到pass.tmall.com，從路徑上來看這裏是設置一些會話標識

這裏有個特殊請求，www.taobao.com/go/app/tmall/login-api.php

後通過驗證，此請求必須攜帶必要的cookie（也就是taobao域名下的cookie），而且Referer必須爲https://www.tmall.com（或http協議，或在尾部加/）

得出結論：這個請求是在tmall域名下經過ajax調用taobao域名的請求，獲得taobao的cookie，而後渲染tmall的吊頂。

從結果來看，這裏設置了不少cookie。

而後，直接刷新tmall.com

這裏能夠看到，vip.tmall.com直接返回200響應碼。

綜上作出如下猜測與總結：

一、淘寶吊頂的會話信息和真實的會話信息存儲方式不一樣；

前者儲存在cookie中，後者儲存在服務端；tmall等其餘拓展域名經過ajax（www.taobao.com/go/app/tmall/login-api.php）同步taobao域名下的cookie

二、訪問tmall等擴展域名，須要判斷會話狀態的請求先根據本域名下的cookie判斷：若是相應的cookie名稱不存在，那麼作302跳轉到https://login.taobao.com/jump下同步cookie到本域名下；若是存在，那麼直接根據cookie判斷服務端的會話狀態，作出200響應；

三、因爲除taobao域名自己外，其餘域名都採用懶加載會話策略，因此taobao域名地位高於其餘域名（或因爲」歷史緣由「）

==============================================================

下面看看京東的作法吧，就簡單啦:

首先，登陸jd

200響應碼很好。

又出現一個passport的請求，url不同哦，返回的jsonp信息包含sso等字樣

果真被執行了，這裏請求了屢次，每次都包含了不一樣的域名，看起來像設置cookie操做。

OK，設置成功

可見京東的處理方式簡單明瞭，直接在登陸完成以後把全部domain所有掃描一遍種下cookie，域名之間的關係看起來比較清晰

======================================================

總結：

淘寶和京東採用了兩種不一樣的策略來實現跨domain的客戶端會話同步機制；

淘寶主要是懶同步，就是用戶訪問到指定的域名，纔去作會話同步；京東則是提早將全部域名的cookie所有準備好。

淘寶的缺陷和不足：吊頂的會話信息不能直接反應真實的會話信息，而且cookie同步策略是有問題的（能夠模擬出吊頂和內容的會話信息不一樣）

京東的缺陷和不足：假設之後的域名增長到好幾十個呢，難道仍是要一次性所有種植cookie嗎？另外，異步請求不可避免會有丟失的風險

本質上，會話在服務端只保留一份，目前使用策略較多的是集中式會話管理；

會話在客戶端的標識須要cookie，那麼會話的同步或共享在客戶端就轉爲cookie的同步了，而cookie因爲跨域就無法直接共享了，那麼跨域的cookie同步就可使用http的302跳轉來實現（不論是ajax請求仍是頁面跳轉）。