我刚刚将一个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号广场,没有登录或会话....这表明可能有一些方法来检查这些常见的黑客攻击尝试没有手动为我设置所有会话上下文的资金capybara句柄。
答案 0 :(得分: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
这与我原始代码的行为相同(上面的问题)。