打算用這貨來代替DRF自帶的TokenAuth，原因是用JWT可以實現(xiàn)登錄/注銷功能。
然而它這兩條默認設置讓我摸不著頭腦：
'JWT_EXPIRATION_DELTA': datetime.timedelta(seconds=300),
'JWT_REFRESH_EXPIRATION_DELTA': datetime.timedelta(days=7),
按照它文檔所述：
JWT_EXPIRATION_DELTA表示issue出去的token多久過期，默認是5mins；
JWT_REFRESH_EXPIRATION_DELTA表示某個token被issue出去后月幌，在多久間隔內可以用它來刷新以便獲取新的token，默認是7天悬蔽。它的原文描述長這樣：（如果我理解有誤扯躺，請告訴我，我的英文不太好）
Limit on token refresh, is a datetime.timedelta instance. This is how
much time after the original token that future tokens can be refreshed
from.Default is datetime.timedelta(days=7) (7 days).
根據這兩個默認設置項蝎困，一個token被發(fā)布出去后录语，5分鐘內便會過期，7天內可以用來刷新獲得新token禾乘，似乎沒啥子問題澎埠，然而問題來了，文檔中關于Refresh Token一節(jié)明確說明：Note that only non-expired tokens will work. 于是實際情況就變成：一個token發(fā)布出去后始藕，5分鐘內可以用來刷新獲得新token蒲稳，5分鐘后就不能用來刷新獲得新token了（報HTTP 400錯誤）。天了嚕伍派，確定這個默認行為不是在開玩笑江耀？你說那個7天的設置有什么卵用沒？
顯然不是我一個人覺得被坑了拙已，請看這個討論：
https://github.com/GetBlimp/django-rest-framework-jwt/issues/92#issuecomment-212846352
解決方案决记？
這個答案似乎有參考價值
追加更新：
經過不斷測試和再三查看文檔摧冀，上面的結論理解有誤倍踪，更正如下：
JWT_REFRESH_EXPIRATION_DELTA的確切含義是自從原始token被發(fā)布出去后，多長時間范圍內它以及它的子孫token可以被用來刷新以獲得新的子孫token索昂。
原始token建车，指的是通過用戶名/密碼驗證后獲得的token（即obtain_jwt_token接口返回的token），原始token刷新后獲得的token1椒惨，以及token1繼續(xù)刷新獲得的token2缤至、token2再獲得token3……形成了一串token鏈，這些token的過期時間都是JWT_EXPIRATION_DELTA康谆。
然而這串token鏈不可能一直無限制刷新下去领斥，直到原始token發(fā)布后的JWT_REFRESH_EXPIRATION_DELTA后，刷新操作將被終止沃暗，框架會返回HTTP 400月洛。之后必須再次調用obtain_jwt_token來獲得新的原始token。
再回到5mins + 7days的默認設置上來孽锥，客戶端首先調用obtain_jwt_token進行登錄操作嚼黔，之后必須每隔小于5分鐘就刷新一次token细层，才能保證不掉線。然而即使一直保持在線唬涧，上限也只有7天疫赎，7天過后必須重新登錄，這才是5mins + 7days的確切含義碎节。
顯而易見捧搞，這種默認策略如果用在手機客戶端上，是很不合適的狮荔∈的担客戶端如果置后臺超過5分鐘，再回去就得重新登錄轴合；就算一直在前臺创坞，連續(xù)用7天后還是得重新登錄。也難怪乎那么多人會無法理解這一組設置的真正用意了受葛。
我目前在客戶端上準備采用30days + 360days的做法题涨，只要一個月內使用一次app，就不用重新登錄总滩，最長可以一年不用重新登錄纲堵。
