Мне было интересно, есть ли недостатки хранения пользовательского принципала в httpcontext.current.items вместо httpcontext.current.user. Я знаю, что вам нужно установить его для каждого запроса, но я должен сделать это с помощью httpcontext.current.user.Asp.Net: Хранение Principal в httpcontext.current.items
спасибо заранее,
Pickels
HttpContext.Current.User это место, где «разрешение инфраструктуры» ожидает Принципала, и будут искать его здесь. Поэтому, когда он там, многие функции, связанные с авторизацией (на основе IsInRole например) будут работать автоматически, когда вы храните его в другом месте, вам придется «взломать» их, чтобы выполнить свою работу.
Roman
Почему бы вам не поставить его где основные жизни?
http://msdn.microsoft.com/en-us/library/system.threading.thread.currentprincipal(v=VS.100).aspx
Это дополнительная информация, которая может помочь другим. Это действительно отвечает на мой собственный вопрос.
В этом проекте они, кажется, делать то, что я задавался вопросом раньше. Они не используют класс, который реализует IPrincipal, но они просто хранят собственный объект пользователя внутри HttpContext.Current.Items. Как они поддерживают это между запросами, которые мне еще предстоит выяснить. Похоже, что для этого они используют какую-то ингаляционную инъекцию.
Я не знал о Thread.CurrentPrincipal. Нужно искать разницу с httpcontext.current.user. – Pickels
Кажется, что пользователь Thread.CurrentPrincipal решил мою проблему, я вчера (http://stackoverflow.com/questions/2776949/moq-unable-to-cast-to-interface). Это была главная причина, по которой я хотел сохранить главную роль где-то еще. Все еще просматривая, какая разница между потоком и httpcontext. – Pickels