sign和token設計

簽名設計

     對於敏感的api接口，需使用https協議

           https是在http超文本傳輸協議加入SSL層，它在網絡間通訊是加密的，因此須要加密證書。

           https協議須要ca證書，通常須要交費。

 

     簽名的設計

           原理：用戶登陸後向服務器提供用戶認證信息（如帳戶和密碼），服務器認證完後給客戶端返回一個Token令牌，用戶再次獲取信息時，帶上此令牌，若是令牌正取，則返回數據。對於獲取Token信息後，訪問用戶相關接口，客戶端請求的url須要帶上以下參數：

         時間戳：timestamp

         Token令牌：token

         而後將全部用戶請求的參數按照字母排序（包括timestamp，token），而後更具MD5加密（能夠加點鹽），所有大寫，生成sign簽名，這就是所說的url簽名算法。而後登錄後每次調用用戶信息時，帶上sign，timestamp，token參數。

例如：原請求https://www.andy.cn/api/user/update/info.shtml?city=北京 （post和get都同樣，對全部參數排序加密）

 加上時間戳和token

       https://www.andy.cn/api/user/update/info.shtml?city=北京&timestamp=12445323134&token=wefkfjdskfjewfjkjfdfnc

      而後更具url參數生成sign

      最終的請求如

         https://www.andy.cn/api/user/update/info.shtml?city=北京&timestamp=12445323134&token=wefkfjdskfjewfjkjfdfnc&sign=FDK2434JKJFD334FDF2

 

其最終的原理是減少明文的暴露次數；保證數據安全的訪問。

具體實現以下：

           1. api請求客戶端想服務器端一次發送用用戶認證信息（用戶名和密碼），服務器端請求到改請求後，驗證用戶信息是否正確。

        若是正確：則返回一個惟一不重複的字符串（通常爲UUID），而後在Redis（任意緩存服務器）中維護Token----Uid的用戶信息關係，以便其餘api對token的校驗。

        若是錯誤：則返回錯誤碼。

          

            2.服務器設計一個url請求攔截規則

               （1）判斷是否包含timestamp，token，sign參數，若是不含有返回錯誤碼。

               （2）判斷服務器接到請求的時間和參數中的時間戳是否相差很長一段時間（時間自定義如半個小時），若是超過則說明該                         url已通過期（若是url被盜，他改變了時間戳，可是會致使sign簽名不相等）。

               （3）判斷token是否有效，根據請求過來的token，查詢redis緩存中的uid，若是獲取不到這說明該token已過時。

               （4）根據用戶請求的url參數，服務器端按照一樣的規則生成sign簽名，對比簽名看是否相等，相等則放行。（天然url簽名                       也沒法100%保證其安全，也能夠經過公鑰AES對數據和url加密，但這樣若是沒法確保公鑰丟失，因此簽名只是很大程                       度上保證安全）。

                （5）此url攔截只需對獲取身份認證的url放行（如登錄url），剩餘全部的url都需攔截。

 

            3.Token和Uid關係維護

               對於用戶登陸咱們須要建立token--uid的關係，用戶退出時須要需刪除token--uid的關係。