烧瓶JWT在每个请求下扩展令牌的有效性

Question

方案

登录的用户将有24小时的令牌到期。在此期间，所有使用@jwt_required装饰器的请求将使 Current 访问令牌的到期延长延长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)
    }

，但这意味着我的应用程序中的每个API调用将是两个请求：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

编辑：现在在此处有文档：https：//flask-jwt-extended.readthedocs.io/en/stable/refreshing_tokens.html

烧瓶-JWT的作者在这里延伸。从技术上讲，您实际上不能扩展令牌，只能用具有新的到期时间的新JWT替换它。但是，您可以通过几种方法进行模拟。

首先，您可以让服务器本身在每个请求中隐式发送一个新的令牌，而不是让客户端请求一个新的令牌。您可以将新的JWT寄回标头，而不是在JSON有效载荷中将其发送回，这样您就不必修改JSON数据来说明新JWT的可能性。不过，您的客户需要意识到这一点，他们需要在每个请求下检查该新标题，并在其存在的情况下用新的JWT替换其当前的JWT。您可能可以使用flask after_request方法来执行此操作，因此您不必将该功能添加到所有端点。将JWT存储在cookie中时可能会产生类似的效果，而差异是cookie自动存储在您的浏览器中（因此您的客户不必在每个请求中手动寻找它们），并且随着CSRF的添加复杂性保护如果您走此路线（http://flask-jwt-extended.readthedocs.io/en/latest/tokens_in_cookies.html）。

上面的工作正常，但是您将创建许多在创建后立即抛弃的访问令牌，这可能不是理想的。上述变体是检查令牌是否即将到期（如果是过期的一半，则可能是更多），如果是这样，则只能创建并返回新的令牌。另一个变体是让客户端检查令牌是否即将到期（通过JavaScript），如果是，则使用刷新令牌请求新的访问令牌。为此，您需要在点（'。'）上拆分JWT，base64从该拆分（索引1）中解码第二组字符串，然后从那里获取" EXP"数据。

您可以做到的第二种方法实际上是等待令牌到期，然后使用刷新令牌生成新的访问令牌并重新制作请求（反应性而不是主动）。这可能看起来像是提出请求，检查HTTP代码是否为401，如果是这样，请使用刷新令牌生成新的访问令牌，然后再次提出请求。

希望这会有所帮助：）

Answer 2

app = Flask(__name__)
app.config["JWT_SECRET_KEY"] = "super-secret"  # Change this!
app.config["JWT_ACCESS_TOKEN_EXPIRES"] = timedelta(hours=1)
app.config["JWT_REFRESH_TOKEN_EXPIRES"] = timedelta(days=30)
jwt = JWTManager(app)

根据您的要求更改时间