Поторопился, в вопросе не было про 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

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

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

Чтобы не задавать глупых вопросов, отвлекся на пару недель на погружение в вопрос внедрения зависимостей (заодно решились и некоторые другие вопросы, для которых я уж было попытался сделать велосипед). Изучал по Марку Симану "Внедрение зависимостей в .NET", как я понимаю, это одна из наиболее серьезных работ на эту тему.

Итого для Autofac:
1) установить в проект autofac и autofac.integration.mvc
2) настроить следующим образом (при запуске проекта):

все. дальше можно создавать контроллерам собственные конструкторы с внешними зависимостями

hVosttНа сайте Autofac примеров достаточно.абсолютный вакуум в нужном разделе
http://autofac.readthedocs.org/en/latest/integration/mvc.html

Konst_Oneпосмотри тут: http://habrahabr.ru/post/136895/ ну на него я и ориентировался, не, я-то разобрался пока, это просто к слову про документацию ))

hVosttэто какой-то левый сайт.какой же левый

hVostt,

плиз, помоги добить тему , не стал спамить в этой ветке, поскольку вопросы достаточно общие.

Shocker.Pro

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

не заботясь о передаче зависимостей через конструкторы и последующее их локальное сохранение. Или тут есть подводные камни?

Ясно.

Собственно, появилась необходимость получить зависимость в базовом (абстрактном) классе контроллера - то есть я не могу внедрить ее через конструктор. То есть получается либо внедрить через свойство, либо получить из DependencyResolver-а

Немножко возвращаясь к аутентификации. Если пользователь не выбирает режим "запомнить меня", Indentity позволяет в следующей сессии достать логин, который был в предыдущей сессии? Или самому возиться с куками?

hVosttShocker.ProНемножко возвращаясь к аутентификации. Если пользователь не выбирает режим "запомнить меня", Indentity позволяет в следующей сессии достать логин, который был в предыдущей сессии? Или самому возиться с куками?

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