3

我刚刚将一个 Rails 应用程序包从 capybara 2.0.0.beta2 更新到当前的 2.0.1 版本。（只是碰巧还在测试版中。）我还将 Rspec 从 2.11.0 更新到 2.12.0 以兼容对如何包含 url 帮助程序的一些更改。

在此更新之前，我进行了一些测试，以验证非管理员用户无法创建新用户以及类似的权限/表单黑客基础知识。我还有一些规范来验证是否涵盖了批量分配攻击。这很容易，而且效果很好，但现在对我来说已经坏了。

context "non-admin users can" do
  before(:each) do
    login_as_user
  end
  it "Not create new users" do
    page.driver.post users_path, { :params => {
      user_name: "user1",
      user_email: "name@example.com",
      user_password: "124mgldkg3",
      user_role: "user"
    } }
    page.status_code.should be 302
  end
end

它声明只尝试去（访问）某处未经授权的工作就好了，但我不能再对不应允许此类用户发布的表单进行操纵发布。对于所有这些请求，我现在都会收到 404。

我完全不确定 Capybara 和/或 Rspec 发生了什么变化。这当然可能是一些小细节导致我的请求“脱离上下文”。它看起来是在没有与访问和表单帖子相同的会话和请求上下文的情况下执行请求。

我想：

  • 使用自定义参数发布，而不是用户可见的表单。
  • 仍然在现有会话和请求上下文中（子域...）

我还没有找到替代技术。我从 Rack::Test 路径开始，但后来我肯定回到了第 1 格，没有登录或会话.... 这表明可能有某种方法可以检查这些常见的黑客尝试，而无需手动设置所有水豚为我处理的会话上下文内容。

4

1 回答 1

3

在深入研究 Capybaras 内部之后，我发现当前执行自定义发布请求的工作方式是执行以下操作：

context "User class users can" do
  before(:each) do
    login_as_user
  end
  it "Not create new users" do
    page.driver.browser.reset_host! # just to be safe
    page.driver.browser.process(:post, users_path, { params: {
      user_name: "user1",
      user_email: "name@example.com",
      user_password: "124mgldkg3",
      user_role: "user"
    }})
    page.status_code.should be 302
  end
end

这在行为上等同于我的原始代码（问题上方）。

于 2012-12-04T12:29:05.477 回答