flask_jwt_extended调用set_access_cookies自动生成CSRF_token及校验报错问题

• flask-jwt-extended默认对cookie存储的JWT开启CSRF保护：当你调用set_access_cookies()方法写入access token到cookie时，框架会自动生成对应的CSRF token，同步写入到名为csrf_access_token的cookie中，这就是你看到额外CSRF相关cookie的成因。
• 开启该保护后，默认对POST、PUT、DELETE等非安全请求方法强制校验CSRF：要求请求必须在X-CSRF-TOKEN请求头中携带和cookie中匹配的CSRF值，否则就会返回Missing CSRF token错误，GET、HEAD、OPTIONS、TRACE这类安全请求方法默认不触发该校验。

根据你的业务场景选择对应方案即可：

场景1：保留CSRF保护（推荐，适配浏览器端/前后端同域调用场景） #

前端每次发起非安全方法的请求时，从cookie中取出csrf_access_token的值，添加到请求头X-CSRF-TOKEN中再发送即可正常通过校验，示例JS获取CSRF token代码：

// 从cookie中提取指定值的工具方法
function getCookie(name) {
  let value = `; ${document.cookie}`;
  let parts = value.split(`; ${name}=`);
  if (parts.length === 2) return parts.pop().split(';').shift();
}
// 发起请求时添加CSRF头
headers['X-CSRF-TOKEN'] = getCookie('csrf_access_token')

如果是Postman测试场景，手动从cookie列表复制csrf_access_token的值，添加到请求头的X-CSRF-TOKEN字段即可。

场景2：关闭CSRF保护（仅适用于纯接口服务、无浏览器端调用的场景） #

直接在Flask配置中添加如下参数，即可关闭cookie模式下的CSRF校验逻辑，框架不会再自动生成CSRF cookie，也不会要求请求携带CSRF头：

app.config['JWT_COOKIE_CSRF_PROTECT'] = False

注意：关闭CSRF保护会带来跨站请求伪造的安全风险，仅当你的接口仅服务于非浏览器客户端（如APP、小程序）时才建议使用该方案。

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