Question

我有几个受过滤器保护的操作会检查logged_in?和admin?，并且如果测试失败则分别吐出401或403错误。什么是绕过这些过滤器的好方法仅在开发模式，以便我可以测试我的应用程序？

我无法完成实际的登录程序，因为它依赖于我在开发过程中无法访问的基础设施。

我也希望能够正确检查401s和403s，所以我不想完全关闭所有的auth过滤器。我希望它在尽可能少的地方定义，所以我不小心让世界绕过生产过滤器。

有没有人找到一个好的压倒一切机制？我想出了一些想法：

分别在过滤条件中添加对params[:logged_in] && RAILS_ENV =~ /dev/和params[:admin] && RAILS_ENV =~ /dev/的检查。这适用于GET，但我必须为我的所有表单和我的AJAX请求添加额外的隐藏字段。
添加仅在开发模式下可用的链接，以便以普通用户或管理员身份登录。这似乎是一个更好的选择。

Answer 1

您可以添加一些auth函数的代码，如果在开发中则返回true。

   def logged_in?
     return true if Rails.env.development?
     ... etc
   end

Answer 2

当你这样做时，你需要做两件事：

在开发过程中传递身份验证信息的另一种方法，
确保在生产中关闭此功能的方法。

第二个我通常在配置文件中进行某种切换，默认为“关闭”。但您也可以检查是否存在具有特殊名称的文件，或者任何适合您的文件。只是为了确保生产中永远不会打开它，您还可以添加进一步的检查，例如当服务器作为特定用户运行时拒绝启用它（如果您有一个特定的用户名，您可以在其下运行生产如果请求不是来自localhost地址，则拒绝使用它。

至于你做了什么，你有很多选择。您可以从开发人员根据自己的口味编辑的文件中读取信息（YAML是一种很好的格式，文件本身的存在可以作为打开它的开关。您还可以包含授权的IP地址。这个文件，如果你真的需要从localhost以外的主机测试）。如果您有一个浏览器插件，例如Web Developer for Firefox，那么设置标题很容易，而且通过HTTP进行功能测试也非常方便。向URL添加额外的参数很受欢迎，但我发现自己并不那么方便。

一旦您获得了身份验证信息，那么您需要做的就是选择插入模拟对象的适当位置，而不是与开发中无法使用的身份验证系统进行通信的实际对象。如果您现在没有这样的位置，则必须重构代码才能创建它。

Answer 3

在配置/环境中，您可以为每个环境提供脚本，以允许您应用特定于环境的设置。

如果这些设置在Rails启动过程中应用得太晚，那么我会考虑在那里覆盖您的身份验证机制的相关方面。这样可以避免在生产应用程序中使用特定于开发的代码，这对我来说似乎是一个好主意！

Answer 4

开发时，在模拟真实身份验证框架的环境中添加一个脚本，或者重新定义基本功能（例如#is_logged_in方法）以始终返回ture，这样您只需更改环境之间不同的部分。< / p>

在开发模式下绕过身份验证和/或授权的好方法是什么？

4 个答案: