自從sina微博oauth2出來以后,第三方集成開發(fā)簡單了很多.Oauth2不像oauth1一樣需要后臺httpclient請求那么麻煩,一切都可以在前臺使用ajax實現(xiàn)了.很多人覺得蹊蹺,對于一個第三方應用,如何不走后臺,而在...

自從sina微博oauth2出來以后,第三方集成開發(fā)簡單了很多.Oauth2不像oauth1一樣需要后臺httpclient請求那么麻煩,一切都可以在前臺使用ajax實現(xiàn)了.很多人覺得蹊蹺,對于一個第三方應用,如何不走后臺,而在前臺使用ajax,來獲取accesstoken?又如何向sina發(fā)起get或post請求?這其中最難解決的問題當屬跨域問題.這篇文章將徹底解決這些疑問.

OAuth

OAuth為一種授權認證機制.它牽扯到服務提供方(sinaweibo),用戶,第三方應用(比如糗事百科).第三方應用想方便用戶可以在它的應用里面直接訪問自己的weibo信息,還可以把第三方的信息發(fā)送到weibo,比如轉發(fā)糗事到sinaweibo.實現(xiàn)這個功能,首先需要第三方應用擁有用戶和sina的授權.在拿到授權以后,第三方應用才能實現(xiàn)集成功能.為什么不直接給第三方用戶密碼而用授權機制,這種問題就不羅嗦了.

拿糗百為例,授權的過程為:

1,糗百打開一個window或iframe,location指向weibooauth授權界面.

2,weibo授權界面是在sina的域名下,是由sina的服務器控制的.授權界面要求用戶填寫sina的賬戶,并確認授權.

3,用戶確認以后,請求發(fā)回給sina.sina產(chǎn)生一個accesstoken,并發(fā)回給糗百.OAuth1使用httpclient,OAuth2使用跨域方法.

4,糗百保留用戶的accesstoken.

5,用戶在糗百發(fā)起分享糗事到sina,糗百將糗事和accesstokent一并發(fā)給sina.OAuth1使用httpclient,OAuth2使用跨域方法.

以上就是授權過程.OAuth1使用類似httpclient的方法與sina交流.這沒有什么疑問,我就不多講了.accesstoken的產(chǎn)生和驗證也不是本文要討論的.本文要討論的是,OAuth2中實現(xiàn)的疑惑.第三方應用是如何通過跨域方法拿到sina的accesstoken的?它又是如何通過跨域方法向sina發(fā)起get或post請求的?

window.postMessage與window.name

在講sina的框架的之前,先熟悉兩個常見的跨域方法.window.postMessage和window.name.

兩個window或iframe之間,只要能拿到對方window的句柄,就可以向對方發(fā)送消息.方法為

1otherWindow.postMessage(message,targetOrigin);

如果對方注冊了事件監(jiān)聽就可以收到message.

1if(window.addEventLister){

2window.addEventLister("message",function(message){});

3}else{

4window.attachEvent("onmessage",function(message){});

5}

通過此種方法,可以在兩個不同域的window之間相互傳遞信息.

因低于IE8的IE瀏覽器是不支持postMessage,所以還可以使用window.name來傳值.如果寫的復雜,則可以使用window.name來模擬postMessage的功能.window.name的局限是,只有同域下才能相互訪問window.name,所以使用window.name來跨域傳值,要花費不少功夫.

window.name跨域最典型的方法是使用代理頁面.比如domainA下有a,domainB下有b.a如何傳值給domainB呢?a可以先創(chuàng)建一個iframe,然后賦予新iframe的contentWindow.name一個message.然后,將iframe的src指向domainB的代理頁面b-proxy.這時候,b可以訪問b-proxy的window.name獲取message.監(jiān)聽window.name變化可以使用setInterval來輪詢.

sinaweibo就是使用的上面方法.首選postMessage,如果不支持postMessage,則使用window.name.由于其js寫的太復雜,壓縮以后更加難看.所以我一直沒看明白它是如何使用window.name的,但原理跟上面是一樣的.

Weibooauth2框架

1,第三方應用首先在sina處申請SDK的使用.從而獲得一個JS的引用地址.

2,第三方將JS的引用放入自己的頁面,看黃色的"Weibo".

3,(授權過程沒有畫在圖上)當?shù)谌较氲玫接脩羰跈嗟臅r候,調(diào)用WB2.login()函數(shù).weibojs彈出一個window,window的location指向sina的oauth2資源.用戶在window中輸入用戶密碼,提交到sina,sina返回一個自關閉頁面.自關閉頁面在關閉前,會將帶回來的accesstoken用window.opener.postMessage()的方法傳回給weibojs所注冊的message監(jiān)聽方法.然后weibojs得到accesstoken,將其存入第三方應用的cookie下.

4,第三方應用開始通過Weibojs向sina發(fā)起資源請求.

5,Weibojs首先創(chuàng)建一個iframe,iframe中引入了sinaclientjs.此iframe跟第三方頁面同源.

6,Clientjs又創(chuàng)建了一個iframe,iframe的src指向sinaxd.jsp,并引入了sina的xd.js.

7,xd.js跟sina同源,xd.js發(fā)起帶有accesstokent的XMLHttpRequest,從sina得到資源.

8,xd.js通過postMessage或者window.name的方式回傳給正在監(jiān)聽等待的clientiframe.

9,clientiframejs再回傳給weibojs.

10,weibojs調(diào)用第三方頁面的callback函數(shù),并把獲得的資源傳給它.

11,callback分析資源,顯示在頁面上.

為什么使用clientiframe?去掉它好像也可以的樣子.我說下對clientiframe的猜想,sina不想暴露太多的接口.weibojs就像接口,盡量短小精悍.將復雜的邏輯處理放在動態(tài)創(chuàng)建的clientjs里面.其次,由于某些低版本的瀏覽器不支持postMessage,所以需要使用window.name來模擬postMessage功能,需要使用代理,我懷疑clientiframe就起到一個代理功能.不過他們的代碼本身寫的就結構龐大,使用了大量的閉包,再用工具對js壓縮了一遍,實在是看不清楚他們?nèi)绾问褂脀indow.name的.萬變不離其宗吧.