Flask+React场景下WTForms如何接收JSON数据完成表单校验

1. 正确实现WTForms接收并完整填充JSON数据的操作步骤 #

先解决基础语法问题，再适配JSON请求的读取逻辑：

• 第一步：修正表单字段定义的语法错误
  编写WTForms表单类时，不要在字段赋值的语句末尾加多余逗号。一旦加了逗号，字段会被Python语法解析为(UnboundField,)元组对象，无法被WTForms注册为可处理的表单字段，自然不存在data属性，也无法参与校验和数据填充。
  正确写法示例：

  from wtforms import Form, StringField, PasswordField
  from wtforms.validators import DataRequired, Email, EqualTo
  
  class RegistrationForm(Form):
      username = StringField("用户名", validators=[DataRequired()])
      email = StringField("邮箱", validators=[DataRequired(), Email()])
      password = PasswordField("密码", validators=[DataRequired()])
      repeatPassword = PasswordField("确认密码", validators=[EqualTo("password")])
  

• 第二步：适配JSON请求的数据读取
  原生WTForms的validate_on_submit方法默认从request.form（即urlencoded、multipart/form-data格式的表单请求）读取数据，前后端分离场景下前端传入的是JSON格式数据，存储在request.get_json()返回的字典中，不能直接复用原有的校验调用逻辑。
  正确的表单实例化流程：
  1. 在路由中通过request.get_json()解析前端传入的JSON数据
  2. 用werkzeug.datastructures.MultiDict将解析后的字典包装为WTForms可识别的类表单结构（避免多值字段读取异常）
  3. 将包装后的MultiDict对象作为formdata参数传入表单类的构造函数，完成字段的初始值填充
  4. 直接调用表单实例的validate()方法执行规则校验，无需依赖validate_on_submit
     示例代码：

  from flask import request, jsonify
  from werkzeug.datastructures import MultiDict
  
  @app.route("/api/register", methods=["POST"])
  def register():
      json_payload = request.get_json()
      # 包装为MultiDict结构传入表单
      form = RegistrationForm(formdata=MultiDict(json_payload))
      if form.validate():
          # 校验通过，执行注册逻辑，可直接通过form.xxx.data读取字段值
          return jsonify({"code":0, "msg":"注册成功"})
      return jsonify({"code":1, "errors": form.errors})
  

• 第三步：wtforms-json的正确使用方式
  若使用wtforms-json扩展，无需手动对JSON字典做处理，只要在表单类定义时继承扩展提供的JSONForm基类，直接将解析后的JSON字典作为入参传入构造函数即可。注意不要手动调用from_json实例方法，这也是很多人使用wtforms-json填充失败的常见原因——误把类初始化逻辑当成实例方法调用，导致数据没有正常传入字段绑定流程。

2. 排查“仅repeatPassword字段可正常填充”的根因 #

可按以下优先级逐行排查：

• 最高概率原因：检查其他字段的赋值语句末尾是否存在多余逗号。如果除了repeatPassword之外的其余字段末尾都加了逗号，这些字段会被解析为元组，无法被WTForms注册到内部的字段映射表中，无论传入多少JSON数据，都无法完成填充；只有没有加逗号的repeatPassword字段会被正常识别绑定，表现为仅这个字段能拿到值。
• 次要原因：检查JSON键名和表单字段名的大小写是否完全匹配。WTForms是严格按字段名匹配数据的，只要存在大小写差异（比如前端传了repeatpassword、后端定义的字段是repeatPassword），就会出现匹配失败的问题。
• 版本兼容原因：检查是否存在wtforms-json版本兼容问题。旧版本的wtforms-json对PasswordField等特殊字段的解析逻辑存在bug，会出现部分字段值读取失败的情况，可升级到最新稳定版本后重试。

3. 无WTForms依赖的CSRF防护实现方案 #

前后端分离场景下可完全基于Flask原生能力实现CSRF防护，核心逻辑采用双重提交Cookie模式，具体实现步骤：

• 第一步：初始化生成CSRF token
  在用户访问应用入口、或调用专门的CSRF token获取接口时，生成一个随机字符串作为CSRF token，将其存在用户的服务端session中，同时将token通过JSON接口返回给前端，前端将token存在内存或localStorage中备用。
• 第二步：前端请求逻辑适配
  前端在发起所有非安全方法的请求（POST/PUT/DELETE等会修改服务端状态的请求）时，将拿到的CSRF token放到自定义请求头中携带给后端，推荐使用X-CSRF-Token作为请求头键名，不要将token存在cookie中由浏览器自动携带。
• 第三步：后端全局校验逻辑
  注册Flask的before_request请求钩子，对所有非安全方法的请求做统一校验：
  1. 跳过GET/HEAD/OPTIONS等安全方法的校验，同时排除OPTIONS预检请求的校验逻辑，避免跨域请求被拦截
  2. 从请求头中读取前端携带的CSRF token
  3. 从用户的session中读取之前存储的CSRF token，和请求头中的值做一致性校验，不一致就直接返回403状态码拦截请求
• 常见的手动CSRF逻辑失效原因：
  • 配置CORS规则时没有允许前端自定义的X-CSRF-Token请求头，导致跨域请求时浏览器直接拦截了请求头传递
  • 校验逻辑没有排除OPTIONS预检请求，导致前端跨域请求流程直接失败
  • 前端只将token存在cookie中，后端却从请求头读取token值，导致取不到对应值

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