sso分析
京東的sso流程:
初始訪問狀態:
cookies:
http請求:
1.在首頁點擊登陸,跳轉至passport.360buy.com,給予驗證cookie alc(可以試試在提交登陸信息前刪除該cookie) cookies
http請求
2.填寫用戶名密碼,提交登陸,驗證alc,登陸成功則給予sso的cookie ceshi3.com,跳轉至首頁 cookies:
3.首頁異步ajax,向passport.360buy.com發起hello請求,hello請求返回json對象a,a包含sso(url地址數組,含請求參數) http請求: 發起hello請求的腳本如下: <script?type="text/javascript">
????????????????????(function?($)?{
????????????????????????$("#shortcut .menu").Jdropdown({?delay:?50?});
????????????????????????var?helloUrl?=?window.location.protocol?+?"//passport.360buy.com/new/helloService.ashx?m=ls";
????????????????????????jQuery.ajax({?url:?helloUrl,
????????????????????????????dataType:?"jsonp",
????????????????????????????scriptCharset:?"gb2312",
????????????????????????????success:?function?(a)?{
????????????????????????????????//if (a && a.info) { $("#loginbar").html(a.info); }
????????????????????????????????if?(a?&&?a.sso)?{
????????????????????????????????????$.each(a.sso,?function?()?{?$.getJSON(this)?})
????????????????????????????????}?
????????????????????????????}?
????????????????????????});
????????????????????}
??????????????????????)(jQuery);</script>
【以上這段是在登出頁發現的,京東首頁實際使用的是壓縮過的,來自http://misc.360buyimg.com/lib/js/2012/lib-v1.js?t=20121204的腳本,兩者相同】
a.sso的內容 "http://sso.360buy.com/setCookie?t=sso.360top.com&callback=?" "http://sso.360buy.com/setCookie?t=sso.minitiao.com&callback=?" "http://sso.360buy.com/setCookie?t=sso.ehaoyao.com&callback=?" "http://sso.360buy.com/setCookie?t=sso.jcloud.com&callback=?" "http://sso.360buy.com/setCookie?t=sso.qianxun.com&callback=?"
4.客戶端回調函數,遍歷a.sso,逐個發起getjson 請求(此時請求目標還是在同一個主域名下,firebug網絡面板中setcookie系列請求,如下圖), 相關代碼: ? ? $.each(a.sso, function () { $.getJSON(this) }) http請求:
5.setcookie系列請求,各自響應一個與setcookie所接受的t參數相應域名的jsonp請求地址(即是接下來的跨域請求),并包含統一的一個c參數
*5到6的銜接,猜測是setcookie的響應同時觸發了sign系列的請求,那必須返回一個js代碼片段,發起getjson請求。
6.客戶端發起sign系列請求,包含c參數,跨主域名請求,響應即為設置ceshi3.com cookie http://sso.360top.com/sign? ?c=6d324d99805593c4aac6abfdd17e67399d73......54763628040 http://sso.minitiao.com/sign?c=6d324d99805593c4aac6abfdd17e67399d73......54763628040 http://sso.jcloud.com/sign? ?c=6d324d99805593c4aac6abfdd17e67399d73......54763613889 http://sso.ehaoyao.com/sign? c=6d324d99805593c4aac6abfdd17e67399d73......54763613889 http://sso.qianxun.com/sign? c=6d324d99805593c4aac6abfdd17e67399d73......54763613890 (上面省略的部分包含了類似“48bd&callback=jsonp1354763638164&_=1354763638814&t=1354763”)
7.所有京東涉及登陸信息的頁面,可對ceshi3.com cookie進行解析,以此作為登陸憑證。 **可以驗證一下 登陸京東后,打開京東奢侈品(360top),刪除cookie ceshi3.com 刷新后顯示未登陸,再打開京東迷你挑(此時又同步了一次cookie),再回京東奢侈品(360top),刷新后依舊是登陸狀態。(迷你挑測試中偶爾會有問題,可以換一個京東產品試試)
8.退出時,跳轉到登出頁面,JS發起getjson請求,刪除所有cookie 京東登出頁上找到以下代碼
<script?type="text/javascript">
jQuery.getJSON("http://sso.360top.com"?+?"/exit?callback=?");
jQuery.getJSON("http://sso.qianxun.com"?+?"/exit?callback=?");
jQuery.getJSON("http://sso.ehaoyao.com"?+?"/exit?callback=?");
jQuery.getJSON("http://sso.360buy.com"?+?"/exit?callback=?");
jQuery.getJSON("http://sso.minitiao.com"?+?"/exit?callback=?");
jQuery.getJSON("http://sso.jcloud.com"?+?"/exit?callback=?");
</script>
總結,整體的關鍵在于360buy.com下客戶端js發起jsonp跨域請求時,傳遞的參數c(猜測是對稱加密后的數據,與登錄憑據cookie ceshi3.com 的值有對應關系)。其他細節都在于服務器端對各系列請求的處理。 如果A域名和B域名(指主域名不同的情況)要共享登陸 B域名下的cookie還是要B自己寫的,jsonp的處理就是告訴B,該寫個什么值,當然傳遞過程中最好進行加密(上面的參數c)。當ABCD等等各產品都設置了統一的憑據,那么就完成了“單點登陸”的要求。不過,對這個憑據進行解析的需求也是很重要的,這里倒未提及。因為涉及到ceshi3.com這個cookie里信息的具體內容,這個驗證過程也只有京東的開發人員才知道了。
1.在首頁點擊登陸,跳轉至passport.360buy.com,給予驗證cookie alc(可以試試在提交登陸信息前刪除該cookie) cookies
http請求
2.填寫用戶名密碼,提交登陸,驗證alc,登陸成功則給予sso的cookie ceshi3.com,跳轉至首頁 cookies:
3.首頁異步ajax,向passport.360buy.com發起hello請求,hello請求返回json對象a,a包含sso(url地址數組,含請求參數) http請求: 發起hello請求的腳本如下:
點擊(此處)折疊或打開
a.sso的內容 "http://sso.360buy.com/setCookie?t=sso.360top.com&callback=?" "http://sso.360buy.com/setCookie?t=sso.minitiao.com&callback=?" "http://sso.360buy.com/setCookie?t=sso.ehaoyao.com&callback=?" "http://sso.360buy.com/setCookie?t=sso.jcloud.com&callback=?" "http://sso.360buy.com/setCookie?t=sso.qianxun.com&callback=?"
4.客戶端回調函數,遍歷a.sso,逐個發起getjson 請求(此時請求目標還是在同一個主域名下,firebug網絡面板中setcookie系列請求,如下圖), 相關代碼: ? ? $.each(a.sso, function () { $.getJSON(this) }) http請求:
5.setcookie系列請求,各自響應一個與setcookie所接受的t參數相應域名的jsonp請求地址(即是接下來的跨域請求),并包含統一的一個c參數
*5到6的銜接,猜測是setcookie的響應同時觸發了sign系列的請求,那必須返回一個js代碼片段,發起getjson請求。
6.客戶端發起sign系列請求,包含c參數,跨主域名請求,響應即為設置ceshi3.com cookie http://sso.360top.com/sign? ?c=6d324d99805593c4aac6abfdd17e67399d73......54763628040 http://sso.minitiao.com/sign?c=6d324d99805593c4aac6abfdd17e67399d73......54763628040 http://sso.jcloud.com/sign? ?c=6d324d99805593c4aac6abfdd17e67399d73......54763613889 http://sso.ehaoyao.com/sign? c=6d324d99805593c4aac6abfdd17e67399d73......54763613889 http://sso.qianxun.com/sign? c=6d324d99805593c4aac6abfdd17e67399d73......54763613890 (上面省略的部分包含了類似“48bd&callback=jsonp1354763638164&_=1354763638814&t=1354763”)
7.所有京東涉及登陸信息的頁面,可對ceshi3.com cookie進行解析,以此作為登陸憑證。 **可以驗證一下 登陸京東后,打開京東奢侈品(360top),刪除cookie ceshi3.com 刷新后顯示未登陸,再打開京東迷你挑(此時又同步了一次cookie),再回京東奢侈品(360top),刷新后依舊是登陸狀態。(迷你挑測試中偶爾會有問題,可以換一個京東產品試試)
8.退出時,跳轉到登出頁面,JS發起getjson請求,刪除所有cookie 京東登出頁上找到以下代碼
點擊(此處)折疊或打開
總結,整體的關鍵在于360buy.com下客戶端js發起jsonp跨域請求時,傳遞的參數c(猜測是對稱加密后的數據,與登錄憑據cookie ceshi3.com 的值有對應關系)。其他細節都在于服務器端對各系列請求的處理。 如果A域名和B域名(指主域名不同的情況)要共享登陸 B域名下的cookie還是要B自己寫的,jsonp的處理就是告訴B,該寫個什么值,當然傳遞過程中最好進行加密(上面的參數c)。當ABCD等等各產品都設置了統一的憑據,那么就完成了“單點登陸”的要求。不過,對這個憑據進行解析的需求也是很重要的,這里倒未提及。因為涉及到ceshi3.com這個cookie里信息的具體內容,這個驗證過程也只有京東的開發人員才知道了。
總結
- 上一篇: mybatis 多表查询 一对一 一对
- 下一篇: qt实现程序密钥注册功能,MD5加密+A