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

Question

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

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

我还希望能够正确检查 401s 和 403s，所以我不想完全关闭所有身份验证过滤器。我希望它在尽可能少的地方定义，这样我就不会不小心让世界绕过生产中的过滤器。

有没有人找到一个好的覆盖机制？我提出的一些想法:

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

Answer 1

执行此操作时需要两件事:

1. 在开发过程中传递身份验证信息的替代方法，以及
2. 一种确保在生产中关闭此功能的方法。

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

至于你做什么，你有很多选择。您可以从开发人员根据自己的喜好编辑的文件中读取信息(YAML 是一种很好的格式，文件本身的存在可以作为打开此功能的开关。您还可以在中包含授权的 IP 地址如果您确实需要从本地主机以外的主机进行测试，请使用此文件)。如果您有一个浏览器插件，例如 Web Developer for Firefox，设置 header 很容易，而且对于通过 HTTP 进行的功能测试也非常方便。向 URL 添加额外参数很流行，但我自己觉得不太方便。

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