Недавно я столкнулся с проблемой запуска веб-приложения asp.net в visual studio 2008. Я получаю, что тип ошибки не разрешен для члена... customUserPrincipal '. Отслеживание различных дискуссионных групп кажется, что существует проблема с веб-сервером Visual Studio при назначении пользовательского принципала против Thread.CurrentPrincipal.
В моем коде я теперь использую...
HttpContext.Current.User = myCustomPrincipal
//Thread.CurrentPrincipal = myCustomPrincipal
Я рад, что у меня ошибка, но он задает вопрос: "В чем разница между этими двумя методами настройки принципала?". Существуют другие stackoverflow questions, связанные с различиями, но они не попадают в детали двух подходов.
Я нашел одно дразнящее сообщение, которое имело следующий грандиозный комментарий, но не объясняло его утверждения...
Использовать HttpConext.Current.User для всех веб-приложений (ASPX/ASMX).
Использовать Thread.CurrentPrincipal для всех другие приложения, такие как winForms, консоль и служба Windows приложения.
Может ли кто-нибудь из ваших гуру security/dot.net пролить свет на эту тему?
В приложении webforms я считаю, что Thread.CurrentPrincipal будет основным для тех, кто выполняет рабочий процесс (Thread).
HttpContext.Current.User будет текущим пользователем веб-пользователя.
В случае приложения forms/wpf это имеет смысл, потому что пользователь, которому вы запускаете приложение, является тем, который вас интересует.
Вы пытаетесь маскировать рабочий процесс или зарегистрированного пользователя?
Первое, что делает объект HttpApplication, когда он приобретает поток, - это установить директиву потока для принципала HttpContext. Это синхронизирует принципы.
Если, однако, вы идете и позже устанавливаете принцип Thread, HttpApplication внутренне по-прежнему имеет другой главный набор для пользовательского контекста. Вот почему вы всегда должны устанавливать его через HttpContext.
(Если вы посмотрите в Reflector, вы можете увидеть сложный код, который запускается, когда вы выполняете "набор" на HttpContext.User - он делает много внутренних вещей с IIS, чтобы правильно установить принципала.)
Эта статья объясняет это?
http://www.hanselman.com/blog/CommentView.aspx?guid=22c42b73-4004-40ce-8af9-47f1b9b434ed
Вот выдержка:
У меня есть некоторый код в пользовательском входе FormsAuthentication ASP.NET, который выглядит примерно так:
// This principal will flow throughout the request. VoyagerPrincipal principal = new VoyagerPrincipal(yada, yada, yada); // Attach the new principal object to the current HttpContext object HttpContext.Current.User = principal;Он вызывается в запросе Global.asax AuthenticateRequest, поэтому все все настройки до того, как начнутся события Page. Это обеспечивает обычай IPrincipal, который интегрирует наш eFinance Server с ASP.NET. Это довольно симпатичная подсистема, ИМХО.
Другие операции рассчитывают на возможность получить этот "контекст вызова" IPrincipal из текущего потока в любое время. В другом разделе код кто-то делал это в середине MIDTRequest (где-то в Page_Load) после того, как ПРОСТО вызвал подпрограмму выше в первый раз:
return Thread.CurrentPrincipal as VoyagerPrincipal;В случае, когда кто-то вызывает первый кусок кода, то ожидает, что сможет вызвать второй кусок в том же HttpRequest, Thread.CurrentPrincipal содержит GenericPrincipal Населенный намного раньше HttpApplication. (Или WindowsPrincipal, в зависимости от ваших настроек).