Thread.CurrentPrincipal.Identity в ASP.NET - безопасно использовать
Внутри обработчика событий AuthenticateRequest я устанавливаю Thread main. Вот часть моего IHttpModule:
public void Init(HttpApplication context)
{
context.AuthenticateRequest += AuthenticateRequest;
}
private void AuthenticateRequest(object sender, EventArgs e)
{
var principal = CreatePrincipal();
HttpContext.Current.User = principal;
}
Но у меня есть сборка, которая не должна иметь доступ к System.Web, поэтому я не могу использовать HttpContext.Current.User, но мне нужно получить доступ к текущему главному. Моя первая мысль заключалась в том, чтобы изменить мой метод на:
System.Threading.Thread.CurrentPrincipal = HttpContext.Current.User = principal;
и при необходимости используйте Thread.CurrentPrincipal.
Но насколько я помню, небезопасно хранить определенные запросы в Thread Local Storage, поскольку несколько потоков могут обрабатывать один и тот же запрос, поэтому я думаю, что это то же самое с Thread.CurrentPrincipal. Или нет?
Ответы
Ответ 1
Я не согласен с ответом Джеффа Мозера.
Стандартный материал авторизации .NET работает с использованием Thread.CurrentPrincipal. например:.
PrincipalPermissionAttribute
PrincipalPermission.Demand
Кроме того, если вы настроите .NET RoleProvider, он установит Thread.CurrentPrincipal в ту же самую главную директорию, что и HttpContext.User.
Поэтому это стандартный способ сделать это, и я бы сделал то же самое в вашем пользовательском коде проверки подлинности (или даже лучше - реализовать его как пользовательский RoleProvider).
Что касается асинхронного ввода-вывода, этот пост в блоге, то указано, что Thread.CurrentPrincipal и настройки культуры автоматически передаются в новый поток.
Использование Thread.CurrentPrincipal, возможно, более безопасно, если ваша библиотека использует принципал для целей авторизации, поскольку ненадежный код может передаваться в качестве аргумента в качестве аргумента, тогда как CAS может помешать ему установить Thread.CurrentPrincipal.
