一，關於授權token，暫時理解為乙個確認雙方的信物。
需求：授權登入
系統a上有生成token以及生產token的方式，系統b希望拿到這個token。
方案1：由系統a生成，然後通過前端去傳給系統b後台，存在安全性問題。
方案2：由系統a和b協商制定某種加密演算法，將某個資料（內部定），進行md5加密，或者其它方式的加密，之後傳給系統b，系統b在解密，一致的話，自己去生成token，然後執行查庫操作等，免除了系統之間後台資料的互動。
目前第二種方案相對安全，在生產上也有實際投入使用的案例。具體細節待補充，可能存在描述錯誤。
涉及到的點：
登入：token的生成，有效期，是否存放伺服器（本次是呼叫登入介面）
報文加密，驗籤：加密演算法，加密演算法的選擇
目前的設計方案：
1，登入（get請求，走閘道器-dubbo-server層）：
2，登入校驗通過後，允許使用者跳轉到某個具體的頁面（登入跳轉介面在其它系統裡。）
有兩種方案 ：1，驗籤後，呼叫登入跳轉介面，返回前端資料。2，驗籤後，返回登入跳轉需要的資料。被登入跳轉介面呼叫。（目前採用2，驗籤後只提供必要的資料）
二，資料庫表的設計問題
需求背景：每個使用者通過資料許可權劃分之後，可以是a商戶的管理員、b門店的店長、c門店下的員工。
設計表結構：待定
需求背景：可以為每個使用者分配角色，且角色的許可權可以不同
設計表結構：
1，許可權表---存放各種許可權資料
2，角色表--存放各種角色資訊
需求背景：儲存儲存省市區等資訊，顯示在前端。
設計表結構：待定
需求背景：儲存所屬行業資訊。行業-餐飲-火鍋，快餐。資料庫表關係可設定如下
三，查詢請求的加解密問題
需求背景：系統a需要從系統b查詢資訊，但資訊涉及到敏感資料，如何解決。
備註：鹽值在雙方系統各存乙份，且保持一致。
這樣就2，
bingo培訓 需求評審一些建議
1 結合背景對產品進行論述比較重要。可以如我們小組論述現狀以及產生現狀的具體原因再到解決方案，向客戶論述當今環境下業務功能的一些痛點與恨點，再闡述我們的產品是如何去解決問題的。2 結合當下熱點問題進行分析。正如我們想要做的系統是乙個問卷系統，正好在評審的前夜我們收到了乙份關於活動的調查問卷，正好是乙...
關於軟體評審的一些想法
軟體評審 軟體評審並不是在軟體開發完畢後進行評審，而是在軟體開發的各個階段都要進行評審。因為在軟體開發的各個階段都可能產生錯誤，如果這些錯誤不及時發現並糾正，會不斷地擴大，最後可能導致我們開發結果不可控。軟體評審是相當重要的工作，也是目前國內開發最不重視的工作。1 評審目標 發現任何形式表現的軟體功...
Shiro的一些知識點記錄
1.subject.isauthenticated 本質上會根據是否讀取到session判斷是否登入，對分布式系統的改造，可以通過sessiondao去快取中讀取。可以從 defaultwebsecuritymanager defaultwebsubjectfactory.createsubject...