Buffalo 的 CSRFToken 默认不是一次性，而是 session 绑定、短期有效且可重复使用；要实现真正的一次性，需用数据库存储带 used 字段和 TTL 的 token，并通过原子更新校验。
Buffalo 中的 CSRFToken 默认就是一次性吗？
不是。Buffalo 的 CSRFToken（通过 auth.CSRFToken() 或模板中 {{ csrf_token }} 获取）默认是 session 绑定、短期有效，但**不是一次性**——同一 token 可在多个 POST 请求中重复使用，直到 session 过期或 token 被显式刷新。
要实现真正的一次性（one-time use），必须手动干预 token 生命周期：生成后立即失效，或校验后主动作废。
如何用 buffalo.Pop 存储并验证一次性 token
推荐做法：将 token 存入数据库（如 PostgreSQL/SQLite），带 used 字段和短 TTL（例如 5 分钟），校验时用 UPDATE ... WHERE token = ? AND used = false 原子更新。成功更新才视为有效。
- 建表示例：
create_table("one_time_tokens", func(t *Table) { t.Column("token", "string", {"size": 64, "primary": true}); t.Column("used", "bool", {"default": false}); t.Column("expires_at", "timestamp"); }); - 生成时写入：
token := uuid.Must(uuid.NewV4()).String(); db.Create(&OneTimeToken{Token: token, ExpiresAt: time.Now().Add(5 * time.Minute)}) - 校验逻辑必须用
db.Raw(...).Exec()或事务包裹的Update，避免先Select再Update的竞态
auth.CSRFToken() 能否直接改造成一次性？
不能安全复用。Buffalo 的内置 CSRF 实现依赖 gobuffalo/mw-csrf，其 token 由 session 加密生成，无服务端状态存储，无法追踪“是否已用”。强行在中间件里每次校验后调用 c.Session().Remove("csrf_token") 会导致后续 AJAX 请求失败（因为模板里的 {{ csrf_token }} 仍会渲染旧值）。
更实际的做法是：绕过内置 CSRF，在关键操作（如密码重置、敏感支付确认）中单独发放一次性 token，并用独立路由 + 独立校验逻辑处理。
- 不要覆盖
auth.CSRFToken()行为 - 对高风险动作，用
POST /api/confirm-action接收token参数，走自定义 handler - 模板中不渲染该 token，而是由前端 JS 从上一步响应中读取并附带发送
常见错误：把 UUID 当一次性 token 直接用
只生成 uuid.NewV4() 并塞进表里，却不设 used 字段或不原子更新，等于没防重放。攻击者截获一次请求，就能反复重放。
另一个坑是忽略时区与 TTL 校验：数据库用 UTC 存 expires_at，但应用层用本地时间比对，导致 token 提前失效或长期有效。
- 始终用
time.Now().UTC()生成过期时间 - 查询时用
WHERE token = ? AND used = false AND expires_at > NOW()（PostgreSQL）或等效表达 - 校验失败时统一返回
400 Bad Request，不要泄露“已用”或“已过期”的具体原因
一次性 token 的核心不在生成多随机，而在服务端状态的精确控制和校验路径的原子性。别省略 used 字段，也别跳过 TTL 检查——这两步漏掉任何一个，就只是个心理安慰。
