Безпека використання поточного потоку [] в рейках

Я постійно отримую суперечливі думки щодо практики зберігання інформації в Thread.currentхеші (наприклад, поточний_користувач, поточний субдомен тощо). Ця техніка була запропонована як спосіб спрощення подальшої обробки в межах рівня моделі (масштабування запитів, аудит тощо).

• Чому мої змінні потоків перериваються в Rails?
• Альтернатива використанню Thread.current в обгортці API для Rails
• Чи безпечні значення Thread.current [] та атрибути рівня класу для використання у рейках?

Багато хто вважає цю практику неприйнятною, оскільки вона порушує схему MVC. Інші висловлюють занепокоєння щодо надійності / безпеки підходу, і моє двоскладове запитання зосереджується на останньому аспекті.

1. Чи Thread.currentгарантовано хеш буде доступним та приватним для однієї і тієї самої відповіді протягом усього циклу?

2. Я розумію, що потік в кінці відповіді цілком може бути переданий іншим вхідним запитам, тим самим витікаючи будь-яка інформація, що зберігається в Thread.current. Чи Thread.current[:user] = nilбуде after_filterдостатньо очистити таку інформацію до кінця відповіді (наприклад, виконавши з контролера ) для запобігання такому порушенню безпеки?

Дякую! Джузеппе

Немає конкретної причини триматися подалі від локальних змінних потоків, головними проблемами є:

• їх важче протестувати, оскільки вам доведеться пам’ятати про встановлення локальних змінних потоку під час тестування коду, який його використовує
• класи, які використовують локальні потоки потоків, потребуватимуть знань про те, що ці об'єкти недоступні для них, але всередині змінної локального потоку, і такий тип опосередкованості зазвичай порушує закон деметера
• не очищення локальних потоків може бути проблемою, якщо ваш фреймворк повторно використовує потоки (локальна змінна потоку буде вже ініційована, а код, який покладається на || = виклики для ініціалізації змінних, може не вдатися

Тож, хоча це не зовсім обговорюване використання, найкраще підхід - не використовувати їх, але час від часу ви потрапляєте у стіну, де локальний потік буде найпростішим можливим рішенням, не змінюючи великої кількості коду та вам доведеться піти на компроміс, мати менш досконалу об’єктно-орієнтовану модель із потоком локальних або змінити досить багато коду, щоб зробити те саме.

Отже, в основному це питання думки, яке буде найкращим рішенням для вашої справи, і якщо ви дійсно рухаєтесь по локальній нитці, я б, безумовно, порадив вам зробити це з блоками, які пам’ятають очистити після вони виконані, як описано нижче:

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

Це гарантує, що локальна змінна потоку буде очищена перед використанням, якщо ця нитка перероблена.

Цей маленький самоцвіт гарантує, що ваші потокові / запитні локальні змінні не затримуються між запитами: https://github.com/steveklabnik/request_store

Прийнята відповідь охоплює питання, але оскільки Rails 5 тепер надає "Абстрактний супер клас" ActiveSupport :: CurrentAttributes, який використовує Thread.current.

Я думав, що надам посилання на це як можливе ( непопулярне ) рішення.

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

Прийнята відповідь є технічно точною, але, як зазначено у відповіді м’яко, а на http://m.onkey.org/thread-safety-for-your-rails - не так м’яко:

Не використовуйте потокове локальне сховище, Thread.currentякщо вам цього не потрібно

Камінь для request_store- це інше рішення (краще), але просто прочитайте там readme з більшої кількості причин, щоб триматися подалі від локального сховища потоків.

Майже завжди є кращий спосіб.