前幾天，花了比較多時間在研究eentity framework, 從今天開始,我要把時間集中在,介紹以前做門戶**的一些好的專案方案了.
首先介紹一下,單點登入吧.乙個企業,要做資訊化整合,要做門戶,首先肯定少不了單點登入.其實單點登入方案有很多.但都大同小異.下面我就介紹我所經歷過的單點登入方案.
一是,路由+模擬post登入方式.
這種方案是,首先把所有要進行單點的站點的域解釋,都解釋在單點登入伺服器上.然後由單點登入伺服器判斷該站點.具體請看下面流程圖.
這種單點登入方案的,對單點單點登入伺服器考驗比較大,因為要把所有的鏈結先指向它,然後再由它轉到對應的伺服器上.但這種方案也有自己的優點,那就是容易形成產品,而且不用更改其他應用程式,就可以實現單點登入.我做過的一家公司,就是使用這種方案,它也是購買別的公司的產品來實現的.
二 是通過url引數傳遞token的方式來實現. 像我們的qq就是通過這種方式來實現的.具體實現,我也在一家公司看過這種單點登入的方式.而且那公司的,單點登入更厲害的是,它的每開啟乙個頁面,都必須要帶token.如果沒帶token,那頁面就沒法訪問. 這種方案要求每個應用程式,都必須要實現對token的解釋. 具體的操作規則,由每個公司自己定義.只要符合一種規則,就可以實現了.因此必須要修改每個應用程式.才能實現單點登入了.
三 是通過共享cookie的方式,來實現.這種方案比較簡單,而且管理也比較容易.不過有個前提.,必須要在同乙個網域名稱下. 這種對於乙個公司內部來說,是比較容易的.現在很多公司,他們的系統都是一級網域名稱一樣.只是2級網域名稱不一樣.
四 是通過url位址挑戰的方式來實現. 這個方案也是我在上家公司親自設計和編碼實現的.
登入方案 使用者單點登入
在微服務專案中，由於使用者往往需要通過閘道器訪問多個微服務，如登入需要訪問使用者微服務，商品瀏覽需要訪問商品微服務，下單需要訪問訂單微服務，支付需要訪問支付微服務。但如何防止使用者操作其他使用者的資料，這就需要在各個微服務中增加授權認證。每個服務都要認證使用者的身份，身份認證成功後，需要識別使用者的...
單點登入方案實戰
頂級網域名稱不一樣的 怎麼辦？這時候就需要cas登場了 1 oauth2，不同的企業之間的登陸，例如 qq登入csdn，應用之間的信任度較低 2 單點登陸，是同一企業的產品系列 不同伺服器上 間的登陸，相互信任度較高 先上個原理圖 1 session cookie機制出現的根源，http連線是無狀態...
單點登入方案筆記
oauth2 不同的企業之間的登入方式 例如 登入csdn用qq登入 單點登入 企業內部的登入方式 一 同頂級網域名稱下單點登入使用session共享的方式 2 攜帶cookie http請求時，攜帶上瀏覽器的cookie cokie裡標識值 jsessionid x 不安全 3 https措施 h...