Почему использует местных жителей потока в Django плохо?
Я использую местных жителей потока для хранения текущего пользователя и объектов запроса. Таким образом, у меня может быть легкий доступ к запросу отовсюду в программе (например, динамические формы), не имея необходимость раздавать их.
Для реализации устройства хранения данных местных жителей потока в промежуточном программном обеспечении я следовал учебному руководству на сайте Django: http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser?version=18
Этот документ был с тех пор изменен, чтобы предложить избежать этой техники: http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser?version=20
От статьи:
С точки зрения дизайна threadlocals являются чрезвычайно глобальными переменными и подвергаются всем обычным проблемам мобильности и предсказуемости, которую обычно влекут за собой глобальные переменные.
Что еще более важно, с точки зрения безопасности, threadlocals представляют огромную угрозу. Путем обеспечения хранилища данных, которое выставляет состояние других потоков, Вы позволяете для одного потока в Вашем веб-сервере потенциально изменять состояние другого потока в системе. Если threadlocal данные содержат описания пользователей или других связанных с аутентификацией данных, те данные могли бы использоваться в качестве основания для нападения, которое предоставляет доступ неавторизованному пользователю или выставляет частные детали пользователя. В то время как возможно создать threadlocal систему, которая безопасна от этого вида нападения, намного легче быть защитным и создать систему, которая не подвергается никакой подобной уязвимости во-первых.
Я понимаю, почему глобальные переменные могут быть плохими, но в этом случае я выполняю свой собственный код моего собственного сервера, таким образом, я не вижу, какую опасность две глобальные переменные создают.
Кто-то может объяснить включенную проблему безопасности? Я спросил многих людей, как они взломали бы мое приложение, если они читают эту статью и знают, что я использую местных жителей потока, все же никто не смог сказать мне. Я начинаю подозревать, что это - мнение, сохраненное незначительными пуристами, которые любят передавать объекты явно.
2 ответа
Я полностью не согласен. TLS чрезвычайно полезен. Его следует использовать осторожно, как и глобальные переменные; но сказать, что его вообще не следует использовать, так же смешно, как сказать, что глобальные переменные никогда не должны использоваться.
Например, я сохраняю текущий активный запрос в TLS. Это делает его доступным из моего класса ведения журнала, без необходимости передавать запрос через каждый интерфейс, включая многие, которые вообще не заботятся о Django. Это позволяет мне делать записи в журнале из любого места кода; регистратор выводит данные в таблицу базы данных, и если при создании журнала запрос оказывается активным, он регистрирует такие вещи, как активный пользователь и то, что было запрошено.
Если вы не хотите, чтобы один поток имел возможность изменять данные TLS другого потока, настройте свой TLS так, чтобы запретить это, что, вероятно, требует использования собственного класса TLS. Однако я не считаю этот аргумент убедительным; Если злоумышленник может выполнить произвольный код Python в качестве вашего бэкэнда, ваша система уже фатально скомпрометирована - например, он может исправить все, что нужно позже, как другой пользователь.
Очевидно, вы захотите очистить любой TLS в конце запроса; в Django это означает очистку в process_response и process_exception в классе промежуточного программного обеспечения.
Несмотря на то, что вы можете перепутать данные от разных пользователей, локализации потоков следует избегать, потому что они скрывают зависимость. Если вы передаете аргументы методу, вы видите и знаете, что вы передаете. Но потоковая локаль - это что-то вроде скрытого канала в фоновом режиме, и вы можете удивляться, что в некоторых случаях метод работает некорректно.
Есть некоторые случаи, когда потоковые локали являются хорошим выбором, но их следует использовать редко и осторожно!