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

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

??? 是真的能實現嗎？如何實現的？好用嗎？安全嗎？。。。。。。

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

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

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

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

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

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

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

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

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

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

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

?

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。