目前想了一個方案,不知道有沒有類似的成熟方案.
1.使用者第一次驗證2.在指定token目錄下建立一個以token值命名的檔案.3.回傳token給使用者儲存.4.客戶端:透過判斷URL200或404進行邏輯處理,服務端:透過判斷檔案是否存在進行邏輯處理.
想到的安全設定是禁止爬蟲爬該目錄,監控使用者對該目錄的連線數防止暴力破解.請問這種方式有沒有BUG及效能問題?或有沒有比這更好的解決方案?
光阴似箭催人老，日月如移越少年。
這個方案，請參考我的另一個回答：/q/10...
這個方案，雖然沒有被當作一個標準，但是卻是普遍在用的方案。 缺點還是有的，例如：
如果產生的token太長，在GET的時候就要考慮是否超過GET請求長度限制（因為URL長度有限），但是太短的token又不能確保高唯一性和安全性
當然，token做使用者令牌也不是安全的。如果在令牌過期之前，token被別人偷到了，他人就可以仿冒此使用者進行操作而不需要登入。
如果要比較安全的方法，那就是用Session伺服器對用戶進行驗證，不過Session跨域問題確實是個老生常談的問題，而token的跨域完全不存在問題，只要能訪問到接口，token是在請求數據裡傳過去的。所以個人觀點是，只有在安全和易用的層面進行取捨了。當然也可以用其他的校驗方式，像是JWT等等，但這種方法比較繁瑣（除非不用自己做輪子）。
1.客戶端提交資訊2.服務端檢查資訊的正確性，如果不合法登陸失敗3.服務端利用演算法產生token,並token儲存在redis等高並發的資料庫中，並設定過期時間 4.服務端將token傳回客戶端5.客戶端保存token6，客戶端下次請求時，攜帶token，服務端驗證token的有效性,有效則通過，無效則驗證失敗
這個方案，請參考我的另一個回答：/q/10...
這個方案，雖然沒有被當作一個標準，但是卻是普遍在用的方案。
缺點還是有的，例如：
如果產生的token太長，在GET的時候就要考慮是否超過GET請求長度限制（因為URL長度有限），但是太短的token又不能確保高唯一性和安全性
當然，token做使用者令牌也不是安全的。如果在令牌過期之前，token被別人偷到了，他人就可以仿冒此使用者進行操作而不需要登入。
如果要比較安全的方法，那就是用Session伺服器對用戶進行驗證，不過Session跨域問題確實是個老生常談的問題，而token的跨域完全不存在問題，只要能訪問到接口，token是在請求數據裡傳過去的。所以個人觀點是，只有在安全和易用的層面進行取捨了。當然也可以用其他的校驗方式，像是JWT等等，但這種方法比較繁瑣（除非不用自己做輪子）。
1.客戶端提交資訊
2.服務端檢查資訊的正確性，如果不合法登陸失敗
3.服務端利用演算法產生token,並token儲存在redis等高並發的資料庫中，並設定過期時間
4.服務端將token傳回客戶端
5.客戶端保存token
6，客戶端下次請求時，攜帶token，服務端驗證token的有效性,有效則通過，無效則驗證失敗