真的能1個用戶帳號登陸所有網(wǎng)站，問U盟？

??? “1個用戶帳號登陸所有網(wǎng)站”，這是筆者在U盟網(wǎng)站首頁看到的醒目提示。

??? 是真的能實現(xiàn)嗎？如何實現(xiàn)的？好用嗎？安全嗎？。。。。。。

??? 帶著一連串疑問，筆者繼續(xù)打開U盟網(wǎng)站http://1users.com，一探究竟。

??? 發(fā)現(xiàn)UID和登陸碼，是U盟用來讓持有UID的用戶得以登陸所有支持UID登陸網(wǎng)站的關鍵，
也就是說，當某個用戶注冊了UID，然后用登陸碼做為密碼就可以登陸其他所有網(wǎng)站了。根
據(jù)筆者現(xiàn)在所看到的理解就是這樣的。

??? 這讓筆者聯(lián)想起曾經(jīng)也在倡導這一理念的“開放ID(OpenID)”的興起和衰落，或許很多
業(yè)內(nèi)人士都根本沒聽說過開放ID是怎么回事。

??? 開放ID(OpenID)是什么？
??? OpenID 是一個以用戶為中心的數(shù)字身份識別框架，它具有開放、分散、自由等特性。
??? OpenID 的創(chuàng)建基于這樣一個概念：我們可以通過 URI （又叫 URL 或網(wǎng)站地址）來認證
一個網(wǎng)站的唯一身份，同理，我們也可以通過這種方式來作為用戶的身份認證。由于URI是整
個網(wǎng)絡世界的核心，它為基于URI的用戶身份認證提供了廣泛的、堅實的基礎。OpenID 系統(tǒng)的
第一部分是身份驗證，即如何通過 URI來認證用戶身份。目前的網(wǎng)站都是依靠用戶名和密碼來
登錄認證，這就意味著大家在每個網(wǎng)站都需要注冊用戶名和密碼，即便你使用的是同樣的密碼。
如果使用 OpenID，你的網(wǎng)站地址（URI）就是你的用戶名，而你的密碼安全的存儲在一個OpenID
服務網(wǎng)站上（你可以自己建立一個 OpenID 服務網(wǎng)站，也可以選擇一個可信任的 OpenID 服務網(wǎng)
站來完成注冊）。
??? 登錄一個支持 OpenID 的網(wǎng)站非常簡單（即便你是第一次訪問這個網(wǎng)站也是一樣）。只需要
輸入你注冊好的 OpenID 用戶名，然后你登錄的網(wǎng)站會跳轉(zhuǎn)到你的 OpenID 服務網(wǎng)站，在你的
OpenID 服務網(wǎng)站輸入密碼（或者其它需要填寫的信息）驗證通過后，你會回到登錄的網(wǎng)站并且
已經(jīng)成功登錄。 OpenID 系統(tǒng)可以應用于所有需要身份驗證的地方，既可以應用于單點登錄系統(tǒng)，
也可以用于共享敏感數(shù)據(jù)時的身份認證。

??? 這就是開放ID(OpenID)，以上解釋來源于OpenID官方網(wǎng)站。http://openid.net.cn/
??? 筆者理解：OpenID就是依靠URI（一長串網(wǎng)站地址）到一個可信任的 OpenID 服務網(wǎng)站來驗證身份的。
??? 那一長串URI很是難記憶，基本上要靠你自己Copy來貼上去，提交后再彈出個OpenID服務網(wǎng)站
來讓你輸入密碼，來完成登陸過程。首先不說那一長串很難記憶URI，有多麻煩，那些眾多的
OpenID服務網(wǎng)站是否就真的可信任嗎？誰可以做OpenID服務網(wǎng)站？有什么審核過程嗎？我們的
密碼都在各些OpenID服務網(wǎng)站上，恐怕很難保證安全吧。種種不便與不信任，導致OpenID漸漸
衰落。或許要等全國人民都講誠信的時候，OpenID興許就能為我們服務了。值得期待。

??? 要不要再來聊聊：我國的誠信體系啥時候健全，筆者看還是不在這里討論了。

??? 還是說回就筆者目前了解到的U盟UID吧。先來比較下UID和OpenID。

??? 1.帳號：
??? >>OpenID這邊叫：URI,（又叫 URL 或網(wǎng)站地址），他是由OpenID給出的，難于記憶，不能自由組合。
??? >>U盟這邊叫：UID，由用戶自己注冊申請的，可以自由組合，例如用自己名字的拼音。
??? 2.密碼：
??? >>OpenID這邊：彈出個驗證窗口，到眾多的OpenID服務網(wǎng)站之一去驗證密碼。（很多人有你的密碼）寒。
??? >>U盟這邊:密碼就是登陸碼，只由U盟生成，通過后臺接口訪問，是隨機的，一次性的，設有效時限的。
??? 3.適用領域:
??? >>OpenID這邊：非金融。
??? >>U盟這邊：任何領域，甚至更安全于現(xiàn)有金融系統(tǒng)登陸認證方式。

??? 筆者看出，OpenID比較聰明的是：自己只制定標準，服務則由眾多的OpenID服務網(wǎng)站來提供。
??? 而U盟完全由自己提供驗證（接口）服務，雖然這樣做相對安全，但如果數(shù)據(jù)流量一大了，U盟能頂?shù)米?#xff1f;
??? 使用中java服務會不會突然蹦掉？
???
??? 在J2EE群集部署方案中，雖然目前的企業(yè)應用都強調(diào)了應用服務器提供的Session復制功能，EJB調(diào)用的負
載均衡能力，但是考慮到目前J2EE潮流發(fā)展的趨勢，已經(jīng)不再使用EJB的負載均衡，同時Session復制也被證明
為影響cluster水平擴展的主要障礙之一。因此對于大容量的J2EE水平擴展群集而言，保持每個節(jié)點的無狀態(tài)性，
不再使用Session來保持全局狀態(tài)是必經(jīng)之路。因為只有每個JVM進程不保持全局狀態(tài)，才能夠保證n個JVM節(jié)點
的冪等性，那些所有涉及到全局狀態(tài)的，必須放在JVM進程之外，例如用戶ID可以使用cookie，session可以放
入數(shù)據(jù)庫，文件可以放在共享存儲系統(tǒng)中。 這樣的方案做下來，前端的apache也僅僅是一個HTTP請求代理，后
面的應用服務器實例幾乎是可以無限水平擴展的，瓶頸永遠不會出現(xiàn)在應用服務器層，只會出現(xiàn)在apache端，
或者數(shù)據(jù)庫端。當然apache不行，還可以用lighthttpd，甚至使用四層交換機硬件進行請求的分發(fā)工作，后端
的單臺數(shù)據(jù)庫不行，還可以使用多個數(shù)據(jù)庫同步復制，甚至使用Oracle Grid。這種群集部署方案下面，
web server退化成為一個請求分發(fā)代理，找不到任何理由使用apache了，對，是lighthttpd出場kick off apache的時候。
如果網(wǎng)站容量大到連lighthttpd都無法及時分發(fā)請求的時候，你還可以用四層交換機來分發(fā)請求，那lighthttpd也該被kick off了。
只有硬件管夠，不管是J2EE，PHP，.NET，還是Rails，都有近乎無限的水平擴展能力。或許U盟根本不擔心如何保障服務
穩(wěn)定性的問題，因為解決方案已經(jīng)很成熟了。

??? 再來展望下U盟的命運幾何呢？
??? 目前國內(nèi)的大型網(wǎng)站大鱷云集，新浪有新浪通行證，網(wǎng)易有網(wǎng)易新浪通行證，騰訊有騰訊通行證，盛大有盛大通行證。。。
但凡大鱷都有自己的通行證，似乎都想把網(wǎng)民們禁錮在自己的王國里。U盟在夾縫中如何動作？求存，還是被吃掉，
筆者也不幫他去想了。

??? 總的來說U盟的UID對于我們廣大的網(wǎng)民來說，總算是有用處的。

?

總結(jié)

以上是生活随笔為你收集整理的真的能1个用户帐号登陆所有网站，问U盟？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。