把網頁的機制照搬過來,利用傳統網頁的記住登陸機制.
使用者輸入正確的使用者名稱和密碼後,建立登陸會話,同時生成乙個記住登陸token保持在伺服器端,同時發個客戶端.
客戶端每次啟動時,通過記錄登陸token新建會話,後續使用便採取session機制.
伺服器端的可用memcache 或 redis 儲存會話.
回味一下這個機制,其中的記住登陸token,也可定個長的有效期,比如30天,
記住登陸token類似oauth 2.0 的 refresh token, session機制裡的session id 類似access token.
只不過,session機制裡的session id 持續使用時,會自動延期.
這個機制的好處是充分利用現有知識,簡單易用,沒有太多新名詞概念
不足之處是不便於分布式認證,還有session機制對效能有一小點影響, 同時不符合restful api無狀態的設計精神.
使用者正確登陸後,生成乙個有效期很長的token(比如半年),儲存在伺服器端,同時發給客戶端, 客戶端的每次請求就以這個token驗證身份.
採用https 傳輸加密, token中途不會被獲取, 而儲存在本地的token其他程式也訪問不了.
對應普通應用而言,這個方案也是可以的.
對於方案二, 如果手機硬體本身被黑客獲取過, 長期token可能被盜,有潛在的風險.
考慮到這一點, oauth 2.0 標準推薦採用refresh token和access token.
refresh token 有效期很長, access token 有效期很短.
使用者登陸後,同時獲得refresh token 和 access token,平時就用 access token, access token 過期後就用refresh token 獲取新的access token.
這個機制只使用乙個短期的token,比如1天.
使用者登陸後, 這個token發給客戶端, 使用者每次請求就使用這個token認證身份, token過期後憑此token換取新的token,乙個過期的token只能換取乙個新的token,這是關鍵. 如果token被盜, 黑客要持續使用也需持續的換取新的token, 伺服器一旦發現,乙個舊token多次試圖換取新token,表示有異常. 這時強制使用者再次登陸.
token舊換新,不一定等過期了才換,應用啟動時就可舊換新,這個視具體情況而定.
重複一下,設計安全機制時,一定要使用https, 沒有https, 多數安全設計都是無用功
token 中文的翻譯就是令牌, 識別身份的依據.
通常token有兩種:
這種token這是乙個唯一的hash值, 要知道這個token是誰,要到乙個中心伺服器查詢.
在中心伺服器,使用者資料可能儲存於檔案或是資料庫或是redis等.
在session 機制的cookie裡 有乙個session id, 本質上也是乙個這類token.
本文所說的token舊換新機制,對上述兩種token均適用.
token 就是乙個字串資訊,就算複製一萬份,彼此也毫無差別,
有了以舊換新的機制,token就有點像實物了, 已經換過了自然不能再換,不管有多少份,只能有乙個換取新的token
當兩個人先後拿著同乙個token 來換新,我們不能判斷到底哪個合法,哪個非法,好吧,兩人都再次登陸確認身份吧.
一種新的乘法
做厭了乘法計算題的卡特，有一天突發奇想，創造了一種新的乘法運算法則。在這套法則裡，x y等於乙個取自x 乙個取自y的所有數字對的乘積的和。比方說，123 45等於1 4 1 5 2 4 2 5 3 4 3 5 54。對於2個給定的數x y 1 x,y 長整型最大數 你的任務是，用新的乘法法則計算x ...
一種新的測試理念
文章分類 軟體開發管理 效能測試可以增加一種新的測試理念，當我們做乙個破壞性測試時，確定乙個破壞點以及相關策略，會得到乙個期望的測試結果。這是測試系統的健壯性。但如果我們輸入的是乙個不確定的破壞點，該輸入會遵循業務邏輯自身繁殖和變異，會產生無法預知的破壞性時，我們這個測試就是不止對系統自身的健壯性的...
一種新的布局方式
通過王老師的講解，讓我認識到了自己的不足，也學到了一種新的布局方式 主要是宋老師 恐嚇 我們，說如果我們去面試，面試官如果要我們使用這種方式，我們怎麼辦，怎麼解決，我才想深入了解下的 王老師提出了兩個問題，她自己也為我們解答了，現在需要我們自己去總結，化為自己的知識。第乙個問題 為什麼會兩個內聯標籤...