关于DRF中Simple JWT TokenRefreshView的两类技术疑问

问题1：代码中if response.data.get('refresh')的作用，以及设置ROTATE_REFRESH_TOKENS=True后未出现refresh字段的原因 #

这段判断确实是为了适配ROTATE_REFRESH_TOKENS=True的场景：当开启这个配置后，每次调用刷新接口获取新access token时，simplejwt会生成一个新的refresh token，同时失效旧的refresh token（若搭配BLACKLIST_AFTER_ROTATION=True）。代码里的判断就是检测响应中是否携带这个新的refresh token，若存在就把它存入httponly cookie，同时从响应体删除该字段，避免暴露在前端。

你设置了ROTATE_REFRESH_TOKENS=True但没看到refresh字段，可能的原因有几个：

• 你使用的CookieTokenRefreshSerializer可能重写了父类逻辑，没有返回refresh token字段；
• 缺少配套配置：ROTATE_REFRESH_TOKENS需要和BLACKLIST_AFTER_ROTATION=True一起使用（需先配置django-redis等缓存后端支持黑名单），否则框架可能不会返回新的refresh token；
• 检查REFRESH_TOKEN_LIFETIME配置，如果refresh token刚生成就调用刷新，还没到可轮换周期，框架也可能不返回新的refresh token。

问题2：access token过期时能否自动刷新Cookie中的access token，以及纯服务端能否处理 #

Django服务端无法自动触发access token的刷新操作，因为HTTP是无状态协议，服务端无法主动向客户端发起请求，只能被动响应客户端的请求。

常见的实现方式是：

• 前端层面：发起业务请求前，检查Cookie中access token的过期时间，当token快过期时，主动调用CookieTokenRefreshView接口获取新的access token，服务端通过Set-Cookie头将新token存入Cookie；
• 服务端兜底：当服务端收到请求发现access token已过期时，返回401状态码，前端捕获后调用刷新接口获取新token，再重试原请求。

纯服务端无法独立完成自动刷新，必须依赖客户端主动发起刷新请求来触发。

内容的提问来源于stack exchange，提问作者dayday