插件flask_jwt_extended

Posted 2023-03-09

参考技术A 书接上文 flask配置生产环境 ，我们了解到了：
如何配置flask+uWSGI+nginx的生产环境

接下来我们来看拓展性更强的jwt插件flask_jwt_extended

安装

什么是Flask-JWT-Extended
之前已经说过jwt是序列化并加密过的json串，那很明显extend则是对之前功能的拓展。那下面我们就该看看拓展的强大之处。
app.py

接下来，因为此插件剔除了自动生成/auth，我们需要拓展user的功能，生成用户有关的：注册、登录、登出等功能，以及用户令牌认证以及刷新、失效等功能。
user.py

claims
这是jwt的数据存储机制

通过这个示例我们可以模拟用户管理机制，如下对item.py的修改，非管理员用户不可以删除item：
注意下get_jwt_claims，说明在上文。

接下来就是一个个介绍特色的时候了：
jwt_optional
官网介绍是，可以可选的保护节点，无论是否发送token，都可以进入节点，然后交给逻辑判断如何处理。比较常见的判定如下：
如果请求中存在访问令牌，则将调用 get_jwt_identity() 具有访问令牌标识的端点。如果请求中不存在访问令牌，则仍将调用此端点，但 get_jwt_identity() 将返回None
示例

create_refresh_token
这个要追溯到create_access_token。一般来说，我们都是将用户权限和用户基本资料存放在这个TOKEN中，但是当用户权限？或者资料变更时，我们就要去刷新用户的资料，或者说当access_token过期了，我们也要去更新access_token。这一部分可以细看 Web API与OAuth：既生access token，何生refresh token
其实这只是定义的问题（不过如果不是自己写TOKEN规则，我们要遵守这个定义）。我们在书写create_refresh_token的逻辑时，不在需要验证用户名和密码即达到了这种效果，如果说个人不这么写逻辑，你也看不出来效果，毕竟两种TOKEN其实是一样的。

这里有另一个概念，令牌的新鲜度fresh=False/True。我们可以根据此处的变更灵活处理一些敏感数据。比如说有些数据只有刚输入用户名和密码时的那段有效认证期才可以使用，当令牌刷新时即判定无效。此处匹配装饰器 fresh_jwt_required()
item.py，POST /item/<name>的逻辑变更。

expired_token_loader
invalid_token_loader
重新定义TOKEN回调错误内容，还有更多的请参考 Changing Default Behaviors

最后我们来介绍黑名单系统
token_in_blacklist_loader by app.py

可以看到此拓展插件给我们的用户管理提供了更多的可能

回到目录