gpt4 book ai didi

post - 使用 capybara 测试特定的帖子请求(表单黑客攻击、权限保护)

转载 作者:行者123 更新时间:2023-12-02 00:15:08 24 4
gpt4 key购买 nike

我刚刚将 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 发生了什么变化。肯定是一些小细节导致我的请求“断章取义”。它看起来像是在没有与访问和表单帖子相同的 session 和请求上下文的情况下执行请求。

我愿意:

  • 使用自定义参数而不是用户可见的表单发布。
  • 仍在现有 session 中并请求上下文(子域...)

我还没有找到替代技术。我从 Rack::Test 路径开始,但后来我肯定回到了第 1 格,没有登录或 session ....这表明可能有一些方法可以检查这些常见的 hacking 尝试不手动设置 capybara 为我处理的所有 session 上下文内容。

最佳答案

在深入了解 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

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

关于post - 使用 capybara 测试特定的帖子请求(表单黑客攻击、权限保护),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13583375/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com