Rails 中 Thread.current[] 使用的安全性

Question

对于在 Thread.current 哈希中存储信息（例如，current_user、当前子域等）的做法，我不断收到相互矛盾的意见。该技术被提议作为一种简化模型层内后续处理（查询范围、审核等）的方法。

• 为什么我的线程变量在 Rails 中是间歇性的？
• 替代使用 Thread.current Rails 的 API 包装器
• Thread.current[] 值和类级别属性在 Rails 中使用安全吗？

许多人认为这种做法不可接受，因为它破坏了 MVC 模式。 其他人对该方法的可靠性/安全性表示担忧，我的由两部分组成的问题集中在后一个方面。

1. Thread.current 哈希值是否保证在其整个周期内对一个且仅一个响应可用且私有？

2. 据我了解，线程在响应结束时很可能会被移交给其他传入请求，从而泄漏 Thread.current 中存储的任何信息。在响应结束之前清除此类信息（例如，通过从控制器的 after_filter 执行 Thread.current[:user] = nil）足以防止此类安全漏洞吗？< /p>

谢谢！ 朱塞佩

Answer 1

没有特定的理由远离线程局部变量，主要问题是：

• 时必须记住设置线程局部变量类
• 测试它们更困难，因为在测试使用它的代码 使用线程局部变量需要知道这些对象对它们来说不可用，而是在线程局部变量内，并且这种间接通常会破坏demeter 定律
• 如果您的框架重用线程，则不清理线程局部变量可能会成为一个问题（线程局部变量已经启动并且代码依赖于 ||=< /strong> 调用初始化变量可能会失败

因此，虽然它并不是完全不可能使用，但最好的方法是不使用它们，但时不时你会遇到线程本地化的问题将是最简单的解决方案，无需进行大量更改代码，你将不得不妥协，有一个不太完美的面向对象模型与线程本地或改变相当多的代码来做同样的事情。

因此，这主要是一个思考问题，哪个将是适合您的情况的最佳解决方案，如果您真的要走线程本地路径，我肯定会建议您使用记住在之后清理的块来执行此操作它们已完成，如下所示：

around_filter :do_with_current_user

def do_with_current_user
    Thread.current[:current_user] = self.current_user
    begin
        yield
    ensure
        Thread.current[:current_user] = nil
    end      
end

如果该线程被回收，这可确保线程局部变量在使用之前被清理。

Answer 2

这个小宝石确保您的线程/请求局部变量不会粘在请求之间： https://github.com/steveklabnik/request_store< /a>

Answer 3

接受的答案涵盖了这个问题，但Rails 5现在提供了一个“抽象超类”ActiveSupport::CurrentAttributes 使用 Thread.current。

我想我会提供一个链接作为可能的（不受欢迎）解决方案。

https://github.com/rails/rails/blob /master/activesupport/lib/active_support/current_attributes.rb

Answer 4

接受的答案在技术上是准确的，但正如答案中温和指出的那样，以及 http ://m.onkey.org/thread-safety-for-your-rails 不太温和：

不要使用线程本地存储，Thread.current 如果你不这样做绝对不必

request_store 是另一个解决方案（更好），但只需阅读自述文件即可了解更多留下来的理由远离线程本地存储。

几乎总有更好的方法。