Разница между http.context.user и thread.currentprincipal и когда их использовать?

Question

Я только недавно столкнулся с проблемой при запуске веб-приложения asp.net в Visual Studio 2008. Я получаю сообщение об ошибке «тип не разрешен для member ... customUserPrincipal».При отслеживании различных групп обсуждения кажется, что существует проблема с веб-сервером Visual Studio при назначении настраиваемого участника для Thread.CurrentPrincipal.

В моем коде я теперь использую ...

HttpContext.Current.User = myCustomPrincipal
//Thread.CurrentPrincipal = myCustomPrincipal

Я рад, что мне удалось избежать ошибки, но возникает вопрос: «В чем разница между этими двумя методами установки принципала?».Существуют и другие стековые потоки вопросов , относящиеся к различиям, но они не касаются деталей двух подходов.

Я нашел один интересный пост, в котором был следующий грандиозный комментарий, но без объяснениячтобы подкрепить свои утверждения ...

Используйте HttpConext.Current.User для всех веб-приложений (ASPX / ASMX).

Используйте Thread.CurrentPrincipal для всех других приложений, таких как winForms,приложения службы консоли и windows.

Может кто-нибудь из вас, гуру безопасности / dot.net, пролить свет на эту тему?

Answer 1

Первое, что делает объект HttpApplication, когда он получает поток, - это устанавливает для субъекта потока принципал HttpContext. Это синхронизирует принципы.

Если, однако, вы позже перейдете к настройке участника потока, у HttpApplication внутри все еще будет другой набор участников для пользовательского контекста. Вот почему вы всегда должны устанавливать его через HttpContext.

(Если вы посмотрите на Reflector, вы увидите сложный код, который выполняется, когда вы выполняете «set» в HttpContext.User - он выполняет много внутренних операций с IIS для правильной установки принципала.)

Answer 2

В приложении webforms я считаю, что Thread.CurrentPrincipal будет основным для всех, кто запускает рабочий процесс (Thread).

HttpContext.Current.User будет текущим вошедшим в систему веб-пользователем.

В случае приложения forms / wpf это имеет смысл, потому что пользователь, под которым вы запускаете приложение, является тем, кого вы интересуете.

Вы пытаетесь маскировать рабочий процесс или зарегистрированного пользователя?

Answer 3

Объясняет ли эта статья это?
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;

Это вызвало запрос AuthenticateRequest от Global.asax, так что все все настройки до событий страницы. Это обеспечивает обычай IPrincipal, который интегрирует наш eFinance Server с ASP.NET. Это довольно симпатичная подсистема, ИМХО.

Другие операции рассчитывают на возможность получить этот «контекст вызова» IPrincipal из текущего потока в любое время. В другом разделе код кто-то делал это в середине MIDTRequest (где-то в Page_Load) после того, как ПРОСТО вызвал процедуру выше в первый раз:

return Thread.CurrentPrincipal as VoyagerPrincipal;

В случае, когда кто-то вызывает первый кусок кода, тогда ожидает, что сможет вызвать второй кусок в том же HttpRequest, Thread.CurrentPrincipal содержит GenericPrincipal Населенный намного раньше HttpApplication. (Или WindowsPrincipal, в зависимости от ваших настроек).