Поторопился, в вопросе не было про MVC )

hVostt,

Просвети, поиз, по новым трендам, мне сейчас как раз авторизацию делать, а во всех моих учебниках - мембершип.

благодарю - поизучаю
как понимаю, в MVC 4 это не работает, надо проапгрейдить проект

hVostt,

Вот только сейчас добрался, поставил пример и офигел, увидев этот многоэтажный огород. Нет, ну я конечно, за неделю могу досконально разобраться, как это все работает и взаимодействует друг с другом. Только вот нафиг мне не требуется вся эта система управления пользователями, ролями, их EF структура управления хранением пользователей/ролей, вся эта двухступенчатая регистрация, счетчики неправильного ввода паролей и страницы блокированных пользователей и чего там еще есть.

У меня пользователи сами не регистрируются, их создает админ. Система наборов прав и совокупностей прав как ролей - тоже своя, хранение и управление пользователями - тоже, проверку логина/пароля я могу обеспечить своей реализацией.

То есть, по большому счету мне нужно от системы аутентификации очень немного, то есть:
1) Обеспечение входа-выхода пользователя с точки зрения его браузера/текущей сессии (как в пределах сессии, так и с функцией "запомнить меня" между сессиями)
2) Знание в контексте контроллера текущего пользователя (либо ID, либо экземпляра моего класса пользователя)

Я буду очень признателен тебе, если ты дашь примерный список классов и методов, достаточных для решения только указанных задач. Это сэкономит мне массу времени.

Последовательность шагов, которая у меня получилась, чтобы прикрутить к проекту MVC4 аутентификацию (не авторизацию) Identity в минимальном варианте (заодно в своей голове все уложу):

1) Проапгрейдиться до MVC5/WebAPI2 (полезная информация тут , тут )

2) Установить пакеты:
Identity Core
Identity Owin
Owin Host SystemWeb

3) Реализовать интерфейс Microsoft.AspNet.Identity.IUser (для примера пусть будет MYUser)
Собственно - там минимальный набор полей - Id и Name, то бишь смело можно прикручивать к любому своему классу пользователя

4) Реализовать интерфейс Microsoft.AspNet.Identity.IUserStore<MYUser> (для примера пусть будет MYUserStore).
Это класс для организации работы с хранилищем пользователей, интерфейс представляет собой простой CRUD-набор методов.

5) Создать startup-класс. Различные варианты его размещения и обнаружения описаны тут . Ориентировочное содержимое:


6) выпилить из web.config winforms-аутентификацию

7) При логине пользователя используется (очень упрощенно) следующая схема
Вторая строка создает ClaimIdentity-объект, содержащий ID и Name пользователя, указанного в первом параметре CreateIdentity. Этого пользователя можно получить через UserManager.FindAsync (который вызовет соответствующие метод хранилища MYUserStore), можно и каким-то другим путем.
Также при необходимости в этот ClaimIdentity можно напихать других Claim-ов (мне это пока не нужно, глубоко не рылся, можно почитать тут , тут ).
SignIn устанавливает пользователю куку, которая и хранит все эти Claim-ы. Соответственно, разлогинить пользователя - SignOut.

Также в контроллере можно использовать атрибут [Authorize] обычным образом

8) При работе авторизованный пользователь представлен объектом ClaimIdentity, через который можно получить его claim-ы, Можно получить ID и Name методами GetUserName и GetUserId.
В представлении объект доступен через @User.Identity (но надо добавить пространство имен Microsoft.AspNet.Identity в представление или в web.config). Соответственно, в контроллере - HttpContext.User.Identity


=====================================================================


собственно, вот. Поправьте плиз, если я что-то неправильно понял. Также у меня остались следующие вопросы:

а) при доступе авторизованного пользователя мне доступен его ID, дальше я могу сам создать экземпляр класса пользователя. Или все-таки он уже где-то создан?

б) связанный вопрос - в вышеописанном примере мне вообще не требовалось реализовывать CRUD-методы для хранилища, если я использую создание экземпляра класса пользователя другими способами. Однако "пустую" реализацию создать все равно пришлось, чтобы иметь возможность создать экземпляр UserManager. В какой момент эта реализация все таки потребуется? Если я решу использовать штатное управление пользователями?

в) как я понимаю, авторизация завязана на куки? Как сейчас принято поступать, если пользователь куки не поддерживает или отключил? просто отказываются работать (попробовал пару веб-приложений - они меня послали при отключенных куках)

г) в примерах, которые я смотрел, экземпляр AuthenticationManager-а не получают каждый раз, а хранят в статической переменной в пределах контроллера. Это нормальная практика, ничем не грозит? А почему для каждого контроллера, почему тогда уж не на уровне приложения?

hVosttда. создание пользователя лучше делать через UserManager.почему? Что такого он дополнительно делает при создании?


И еще, вдруг до меня дошло. На уровне модели у меня нет ни контекста контроллера, ни сессии и т.п. То есть единственный способ иметь текущего пользователя в модели (а это нужно в 99,5% случаев) - передавать его через все конструкторы модели? Или есть какая-нибудь менее напряжная метода?

hVosttможно через IPrincipal получить Id пользователяб-р-р, почитал-не понял, как это можно сделать на уровне модели, не имея контекста... экземпляр модели ведь вообще существует сам по себе. Поясни, плиз, бестолковому.

А, спасибо!!!
Я-то понимал, что единственная ниточка, связывающая модель и контекст - это поток, не не думал, что настолько напрямую можно получить

Я думаю, что сделаю свой метод расширения для Thread

Гм, получается такая шняга.
Через тред я могу получить ид/имя пользователя, а мне постоянно нужен для работы экземпляр класса пользователя. Создание экземпляра = обращение к базе, поэтому хотелось бы создавать его не более одного раза за реквест.
Попробовал создать тред-статик поле для экземпляра класса пользователя, но этот тред в пуле и может предоставляться другим реквестам.

Подкиньте гениальную идею, как бы мне иметь легкий и безопасный доступ к экземпляру класса пользователя (созданному в начале этого реквеста) из любого места в пределах исполнения реквеста.