Flask JWTは、各リクエストのトークンの有効性を延長します

Question

シナリオ

ログインしたユーザーのトークンの有効期限は24時間になります。その期間内に、@jwt_requiredデコレータのすべてのリクエストは、の現在のアクセストークンの有効期限をさらに24時間延長します。最大有効期間は168（24 * 7）時間です。

access_tokenとrefresh_tokenを使用できます。

ret = { 
     'access_token': create_access_token(identity=username, fresh=True), 
     'refresh_token': create_refresh_token(identity=username) 
    } 

しかし、それは私のapplicatinoからのすべてのAPIコールが2つのリクエストになります意味： 1.実際のHTTPリクエスト 2.認証トークン

@app.route('/refresh', methods=['POST']) 
@jwt_refresh_token_required 
def refresh(): 
    current_user = get_jwt_identity() 
    ret = { 
     'access_token': create_access_token(identity=current_user) 
    } 
    return jsonify(ret), 200 

を更新暗黙的に認証を拡張する方法がありますトークン？

Answer 1

フラスコの作者jwt-extended here。技術的には、実際にはトークンを拡張することはできません。新しい有効期限を持つ新しいJWTに置き換えることができます。あなたがこれをシミュレートできるいくつかの方法があります。

最初に、クライアントが新しいトークンを要求するのではなく、サーバー自体がすべての要求に対して新しいトークンを暗黙的に返すようにすることができます。新しいJWTをJSONペイロードではなくヘッダーに戻すことができるので、新しいJWTの可能性を考慮してJSONデータを変更する必要はありません。クライアントはこれを認識する必要がありますが、リクエストごとに新しいヘッダをチェックし、現在のJWTがあればそれを新しいものに置き換える必要があります。おそらくフラスコのafter_requestメソッドを使用して、この機能をすべてのエンドポイントに追加する必要はありませんでした。 JWTをクッキーに保存するときにも、クッキーが自動的にブラウザに保存されるという違いがあるため（クライアントが毎回リクエストで手動で検索する必要がない）、CSRFが複雑になりますあなたがこのルートに行くならば保護（http://flask-jwt-extended.readthedocs.io/en/latest/tokens_in_cookies.html）。

上記はうまくいくはずですが、作成直後に破棄される多くのアクセストークンを作成することになりますが、これはおそらく理想的ではありません。上記のバリエーションは、トークンが期限切れに近づいているかどうか（おそらく期限切れの半分以上になっているかどうか）をチェックし、そうであれば新しいトークンを作成して返すだけです。これのもう一つのバリエーションは、トークンが（javascriptを介して）期限切れになるかどうかをクライアントがチェックし、そうであればリフレッシュトークンを使用して新しいアクセストークンを要求することです。これを行うには、JWTをドット（ '。'）で分割し、base64でその分割（インデックス1）から2番目の文字列をデコードし、そこから 'exp'データを取得する必要があります。

2番目の方法では、実際にトークンが期限切れになるのを待ってから、リフレッシュトークンを使用して新しいアクセストークンを生成し、要求を再作成します。これは、HTTPコードが401であるかどうかを確認し、リフレッシュトークンを使用して新しいアクセストークンを生成した後、要求を再作成するように要求を行うように見えます。

希望します。