一、總述
二、環境配置
[三、業務servers管理]
[四、使用者資訊同步]
[五、token的攔截、生成、驗證（服務端）]
[六、概念辨析：session、cookie、token的區別與token儲存]
[七、token的分享（瀏覽器端）]
[八、安全性措施]
[九、使用者體驗]
[十、效能]
各位，實在抱歉！sso原本是我的畢業設計，但是出於某個原因，我決定留級，畢設暫時擱淺！這段時間忙著準備面試的事情，系統學習前端中ing! 這是這個系列被擱淺的原因之一！另乙個原因在於，我發現沒有經歷過企業開發，真的在某些環節上很難理解sso中一些讓我非常困惑的問題！比如，我一直困惑的這個問題，這非常有可能是乙個很簡單的問題，但是我往往是被這種問題困惑住。比如，「效能」問題，大四實習年一直沒在it企業，討論「效能」心裡很虛，我更想接觸一定的開發之後，心裡更加有底的寫下問題的答案。沒出問題的話，這個系列會在6月中旬繼續更新，希望8月能搞定。
今天我要講兩個故事，一家高階商場的故事和一家普通商場的故事。
1.高階商場的故事
從前有個老闆叫c/s，他開了這樣一家高階商場叫「tcp/ip server"。專門服務註冊了vip的顧客。他們對待註冊了vip的顧客的服務非常的高階。怎樣高階？每一位vip顧客進來購物，就會有乙個服務員全程陪同。這些服務員提供所有的服務，非常的有才能。但就是都很沒有記性，永遠都記不住自己是在服務哪位顧客。這也怪不得服務員，誰叫每個vip顧客都長得一模一樣呢？於是老闆就讓服務員全程牽著顧客的手，並且手裡拿著一張紙條，紙條上面寫著顧客的姓名、性別、年齡、餘額等等資訊。這樣他們就能叫出顧客的尊稱，而且因為牽著手，所以不至於跟顧客走丟。真為這一群奇葩著急啊ヽ(￣д￣;)ノ!!!這些服務員這一群體被學術家們稱為「progress」，而顧客這一群體被學術家們稱為「client」
我很好奇高階商場賣的都是些什麼東西。從商業角度來說，全程一對一的服務成本可真高啊。
2.普通商場的故事
後來，有乙個老闆叫b/s，他覺得c/s是個傻x，全程一對一的服務成本高，收益小。於是他開了一家普通的商場叫"http server"。跟"tcp/ip server"商場一樣，他的"http server"也是需要註冊vip的。但是他的服務員們並不會全程陪同顧客購物。總的來說，他們提供兩樣服務：1.詢問 2.收銀。每個服務員在處理完某個顧客的詢問服務或者收銀服務後，就可以為另乙個顧客服務。"b/s"以為它的商場會比那個沒頭腦的「c/s」的商場收益更好！很顯然嘛，一樣多的服務員，他的店能服務更多的顧客。
天真的b/s，可憐的b/s。他差點就破產了～ 還不是那群讓人著急的服務員！開張第一天，他們就惹來了滿滿的差評。他們總是記不住顧客買了什麼東西，根本沒有辦法收銀；而且顧客上前要詢問他們「node.js的產品在哪個貨架？」、「python有多少種框架產品？」等問題的時候，這群服務員總是沒有辦法先叫出顧客的名字來給予顧客問候。顧客覺得他們都很沒有禮貌～～～這也怪不得服務員，健忘是他們的天性，更何況每個顧客的相貌、穿著、聲音又都完全一樣，他們可是要乙個人服務多個顧客的！
b/s決定關店整改!!!他給每個服務員配備了乙個記錄器。有乙個服務員專門負責把進店的會員資訊寫進記錄器，然後把一串唯一的id寫在一種叫做cookie的紙上，把紙貼在顧客額頭上......沒錯，貼在額頭上。其它服務員只要往記錄器輸入顧客頭上的id，就能查詢到顧客的資訊，這樣服務員就不會因為叫不出顧客的名字被說沒禮貌了；並且可以把顧客要買的東西，臨時的記錄在記錄器裡面。當然啦，記錄器裡的記錄是整個商場共享的。所以，即便顧客a買《黑客與畫家》的時候是服務員a給記錄的，買《寫給大家看的設計書》的時候是服務員b給記錄的，結算的時候又是服務員c，他們搞錯了。b/s非常自豪的把這種記錄器機制叫做session機制，真搞不懂他為什麼要這麼叫。就這樣，b/s的「http server」商場以更低的成本獲得了更大的收益～ 他發跡了。
登入就是通過驗證（密碼驗證、指紋驗證、聲音驗證、人面驗證、dna驗證...），向服務端表明你是誰？並且讓服務端記住你是誰。對於c/s的架構來說，要記住你是誰太容易了～ 客戶端跟服務端建立的tcp/ip連線就能很好的表明你誰，乙個程序服務乙個客戶端，只要在程序空間裡寫個變數就ok了！但是對於b/s架構來說，因為是無狀態的，服務一結束就斷開(現在的長連線也還是會斷)，要記住你是誰真心太不容易了～ 所以只能由客戶端來告訴服務端：「我是誰。」，也就是給客戶端乙個id，然後服務端有個全域性的空間(session)用於記錄id對於的資訊，類似於map。對於每一次的服務請求，服務端都要拿著客戶端給的id，去session查詢這個id是不是登入了，如果是則怎樣怎樣，如果不是就叫使用者登入（假設每個頁面的訪問都要求使用者登入）。拿著id去session查詢id是不是登入了這個過程我們把它叫做檢驗，這點先提前說明下，有點重要！登入成功後，就把這個id做乙個標記，表示登入。什麼樣的標記？你可以在這個id的session空間裡設定乙個變數叫mark用來表示登入了，但是不會有人這麼做的，至少也得設定個username的變數。不然你怎麼知道這個使用者是哪乙個使用者呢？有username就可以再去資料庫查詢更多的資訊，當然也可以把更多的資訊寫到session裡面，這裡不做討論。
很早期的公司，一家公司可能只有乙個server，慢慢的server開始變多了。每個server都要進行註冊登入，退出的時候又要乙個個退出。使用者體驗很不好！你可以想象一下，上豆瓣 要登入豆瓣fm、豆瓣讀書、豆瓣電影、豆瓣日記......真的會讓人崩潰的。我們想要另一種登入體驗：一家企業下的服務只要一次註冊，登入的時候只要一次登入，退出的時候只要一次退出。怎麼做？
一次註冊。 一次註冊不難，想一下是不是只要server之間同步使用者資訊就行了？可以，但這樣描述不太完整，後續講使用者註冊的時候詳細說。實際上使用者資訊的管理才是sso真正的難點，只是作為初學者，我們的難點在於實現sso的技術！我們先討論實現手段。
一次登入與一次退出。 回頭看看普通商場的故事，什麼東西才是保持登入狀態關鍵的東西？記錄器（session）？那種叫做cookie的紙張？寫在紙張上的id? 是session裡面記錄的資訊跟那個id，cookie只不是記錄id的工具而已。客戶端持有id，服務端持有session，兩者一起用來保持登入狀態。客戶端需要用id來作為憑證，而服務端需要用session來驗證id的有效性（id可能過期、可能根本就是偽造的找不到對於的資訊、id下對應的客戶端還沒有進行登入驗證等）。但是session這東西一開始是每個server自己獨有的，豆瓣fm有自己的session、豆瓣讀書有自己的session，而記錄id的cookie又是不能跨域的。所以，我們要實現一次登入一次退出，只需要想辦法讓各個server的共用乙個session的資訊，讓客戶端在各個網域名稱下都能持有這個id就好了。再進一步講，只要各個server拿到同乙個id，都能有辦法檢驗出id的有效性、並且能得到id對應的使用者資訊就行了，也就是能檢驗id。
以server群如何生成、驗證id的方式大致分為兩種：
實際上，基本是用token代替session的方式，也有非常多種實現方法。是我先去自己實驗時的方案。
sso-server負責使用者的登入（當然也有註冊、修改基本使用者資訊、退出功能），它的作用有兩點：
簡單聊天室 總述
簡單聊天室 伺服器 什麼是簡單聊天室？什麼又是伺服器？相對應的，什麼又是客戶端？伺服器 客戶端，伺服器將之比作移動公司，而我們的手機就是客戶端。我們打 就是向伺服器申請通話請求，伺服器在根據請求作出應答，即連線另一部手機，使之進行通話連線。在計算機中，我們可以根據ip和埠建立伺服器 1.獲得ip 在...
make之makefile 二 總述
一 makefile裡有什麼？makefile裡主要包括了五個東西 顯式規則 隱晦規則 變數定義 檔案指示和凝視。1 顯式規則。顯式規則說明了，怎樣生成乙個或多的的目標檔案。這是由makefile的書寫者明顯指出，要生成的檔案，檔案的依賴檔案，生成的命令。2 隱晦規則。由於我們的make有自己主動推...
heritrix設計詳解 一 總述
讀了一段時間的原始碼，結合網上的文件和自己的理解來詳解下heritrix的體系結構，總體來說hertitrix是乙個設計優良的框架，擴充套件性極強，除了無法實現分布式之外，其他部件都可以被擴充套件。b 體系結構 b frontier 邊界部件 跟蹤哪個預定的uri將被收集,和已經被收集的uri,選擇...