Camping 作为 Ruby 生态中极轻量的 Web 框架，一直强调用最少的代码把请求跑通。很多从 Rails 转过来的开发者会不适应：没有庞大的 helper 库，也没有默认开启的安全套件。Camping::Helpers::FormTag 模块保留了一套精简的表单构建方法，用起来像写纯 HTML 但又能复用 Ruby 逻辑。不过它默认只负责拼字符串，不会往表单里塞 CSRF 令牌，安全防护需要额外补上。下面把这两件事放在一起讲清楚。
FormTag 模块的核心方法与渲染逻辑
Camping::Helpers::FormTag 本质上是一组返回字符串的方法，常见的有 form_tag、input_tag、label_tag、select_tag、textarea_tag 和 submit_tag。你可以在视图或控制器中直接调用它们，但更推荐放进 Camping 的 helper 模块，让所有页面共享。与 Rails 的 form_for 不同，它不绑定模型对象，也不会根据对象状态自动设置 method 或 class。你需要手动指定 :action、:method 等属性。这种设计牺牲了一点便捷性，换来了完全透明的 HTML 控制权。
以 form_tag 为例，它的职责是拼出 <form> 开始标签和结束标签，中间的块内容通过 capture 接收。下面这个简化实现能够体现它的工作方式：
module Camping::Helpers
module FormTag
def form_tag(opts = {}, &block)
method = opts.fetch(:method, 'post')
action = opts.fetch(:action, '')
attrs = opts.reject { |k, _| [:method, :action].include?(k) }
html = "<form method=\"#{method}\" action=\"#{action}\""
attrs.each do |key, value|
html << " #{key}=\"#{value}\""
end
html << ">"
html << capture(&block) if block
html << "</form>"
html
end
def input_tag(type, opts = {})
name = opts.fetch(:name, '')
value = opts.fetch(:value, '')
"<input type=\"#{type}\" name=\"#{name}\" value=\"#{value}\" />"
end
def submit_tag(value = '提交')
"<input type=\"submit\" value=\"#{value}\" />"
end
end
end
上面只是一个教学版实现，真实源码会更谨慎地处理属性转义和布尔属性。注意字符串里的 < 和 > 是转义后的形式，如果直接返回未转义的字符，在模板中它们会被浏览器解析成真正的标签。这类辅助方法可以大幅减少视图里的重复代码，但没有任何安全过滤，攻击者输入的 <script> 会原样进入页面，所以调用前必须自行做 HTML 转义。
除了生成标签，input_tag 还支持一个很实用的技巧：把参数中的 value 与请求参数合并，避免表单重填时丢失数据。例如用户提交失败后返回表单页，可以写 value: @params['username']，这样输入框会保留上次填写的内容。这个细节在传统服务端渲染中体验提升明显，也是 FormTag 值得继续使用的理由之一。
CSRF 攻击原理与 Camping 的默认缺位
跨站请求伪造的本质是浏览器会在跨域请求中自动携带目标站点的 Cookie。攻击者可以在自己的页面里放一个不可见的表单，指向受害站点的敏感操作，比如 method="post" action="http://目标站/delete"。如果受害者已登录，浏览器会在提交时带上 Cookie，服务器无法区分这是用户主动点击还是恶意页面自动触发。请求一旦到达，后端只看到合法会话，却看不到用户真实的操作意图。
常见的防御方式是在 POST 请求中加入随机令牌，并在服务端校验。Rails 通过 protect_from_forgery 自动处理，Django 有 {% csrf_token %} 标签，而 Camping 没有这种内建机制。它只提供基础的表单辅助方法，不会在 form_tag 里插入 token。如果你只是用 FormTag 生成表单而不做额外处理，应用面对 CSRF 几乎是不设防的。很多 Camping 项目上线后只做了输入校验，却遗漏了这一步，导致账号操作可以被轻易构造。
需要特别澄清的是，CSRF 不同于 XSS。XSS 是攻击者向页面注入脚本，CSRF 是攻击者诱导浏览器发起合法请求。因此仅对输入做转义并不能防住 CSRF，必须从请求来源和令牌机制入手。理解了这一点，后面的集成方案才不会被误用。
用 Rack::Csrf 与 FormTag 配合实现自动令牌注入
Camping 基于 Rack 架构，可以方便地引入 Rack::Csrf 中间件。先在 config.ru 中加入 use Rack::Session::Cookie 和 use Rack::Csrf，因为令牌需要依赖会话存储。顺序很重要，Session 要在 Csrf 之前，否则中间件拿不到会话，后续校验会全部失败。
# config.ru require 'camping' require 'rack/csrf' Camping.goes :Blog use Rack::Session::Cookie, secret: 'change_me' use Rack::Csrf, raise: true run Camping::Blog
中间件加载后，每个请求的环境里都会有一个 Rack::Csrf.token(env) 生成的令牌值。此时可以扩展 FormTag 模块，让 form_tag 在 method 为 post 时自动附加一个隐藏字段。关键点在于要能访问当前请求的 env，在 Camping 视图上下文中可以通过 @env 获得。
module Camping::Helpers
module FormTag
def form_tag(opts = {}, &block)
method = opts.fetch(:method, 'post')
action = opts.fetch(:action, '')
html = "<form method=\"#{method}\" action=\"#{action}\">"
if method.to_s.downcase == 'post'
token = Rack::Csrf.token(@env)
html << "<input type=\"hidden\" name=\"_csrf\" value=\"#{token}\" />"
end
html << capture(&block) if block
html << "</form>"
html
end
end
end
这样每次调用 form_tag 生成的 POST 表单都会自动带上 _csrf 隐藏字段，Rack::Csrf 会在请求进入控制器前校验该字段。如果校验失败，中间件会抛出异常或返回 403，具体行为由 :raise 和 :field 选项控制。对于 AJAX 请求，也可以从 X-CSRF-Token 头读取令牌，逻辑类似。
如果不想依赖中间件，也可以手动实现令牌校验。在会话中保存一个随机字符串，form_tag 把该值写入隐藏字段，控制器在处理 POST 前比对提交值与会话值是否一致。手动实现的好处是逻辑完全透明，缺点是需要自己处理令牌更新、过期和错误提示。对于大多数项目，直接使用 Rack::Csrf 更省心。但不管用哪种方式，都要保证隐藏字段名称一致，否则中间件根本读不到值。
在控制器里处理校验失败时，通常可以捕获 Rack::Csrf::InvalidToken 异常并返回统一的错误页面。Camping 的路由定义内部可以用 begin/rescue 包住处理逻辑，记录日志后返回 403 状态，而不是让异常直接冒泡到用户眼前。这样既保证安全，又避免暴露过多内部信息。
令牌校验之外的几个关键细节
有了中间件和隐藏字段并不等于万事大吉。令牌必须与当前会话绑定，不能全局共用，否则攻击者只要自己登录一次就能拿到有效令牌用于其他受害者。Rack::Csrf 默认使用 session 存储 token，因此天然绑定了会话。如果选用自定义实现，务必在用户登录成功后轮换令牌，防止会话固定攻击。
另一个容易忽略的细节是 GET 请求不应产生副作用。CSRF 令牌通常只保护 POST、PUT、DELETE 等不安全方法。如果你的删除操作还允许用 GET 完成，即使有令牌也可能被绕过。建议把改变服务器状态的动作全部改成 POST，并在路由层做方法限制。Camping 的路由定义里可以用 r.post 和 r.get 区分，不要图省事把删除链接做成 GET。
还需要注意令牌的注入时机。把 form_tag 扩展放在 helper 层比每个视图手动写隐藏字段更可靠。因为集中处理可以避免某个表单忘记加入 token。但这样的扩展必须保证 @env 存在，否则在测试或非请求上下文中会崩溃。可以加一个 respond_to?(:@env) 或 rescue 保护，避免单元测试里调用 form_tag 时报错。
常见错误与调试方法
实现 CSRF 保护时最常见的错误是中间件顺序不对。如果 Rack::Csrf 放在 Rack::Session 之前，令牌无法持久化，每次请求都会生成新值，导致表单刚渲染出来就校验失败。调试时可以打印 env['rack.session'] 和 env['csrf.token'] 确认两者是否一致。另一个问题是忘记在 AJAX 请求中携带令牌。很多前端代码使用 fetch 提交数据，但不会像表单那样自动带隐藏字段。此时需要手动从页面 meta 标签或 JavaScript 变量中读取 token，并设置到 X-CSRF-Token 请求头。服务端中间件通常同时支持请求头和表单字段，配置时要确认 :header 选项没有写错。
最后一个提醒，不要把令牌直接放在 URL 查询参数中。URL 可能被浏览器历史、服务器日志、Referer 头泄露。CSRF 令牌就像会话凭证一样，应该只通过 POST 请求体或专用请求头传输。坚持这一点，才能让 FormTag 构建的表单在保持简洁的同时，真正具备抵御跨站请求伪造的能力。