Комментарии 9
А я просто делал свой
Правда это было давно 2-3 версия, может сейчас что то поменялось. Но работало.
Примерно как тут описано.
AuthorizeAttribute где проверял залогинен ли юзер и его роли.Правда это было давно 2-3 версия, может сейчас что то поменялось. Но работало.
Примерно как тут описано.
а что все так сурово, вы по сути выкинули хороший, интегрированный со всем кусок ASP и сделали свой велосипед? Есть хоть одна причина почему не использовать FormsAuthentication + кастомные Membership/Role/Profile провайдеры? DI там и так везде возможны, причем через конструктор а не через DependencyResolver, т.е. с тестированием и моками проблем не возникнет.
плюс с 4.5 ввели ClaimIdentity и ClaimsPrincipal
Там по ссылке есть изыскания на тему того, что стандартный провайдер использует устрашающие хранимые процедуры для своей работы. Но это было в MVC3. А тут используется MVC4 и новый провайдер использует Entity Framework, соответственно вызывает не процедуры, а делает непосредственные запросы. Запросы простые и их немного, как мне кажется врядли велосипедом можно что то наэкономить в плане производительности. Хотя сам по себе опыт по созданию своего провайдера это тоже хорошо.
Правда тут уже усть новая причина: для доступа к бд используется Linq2SQL и велосипедный мембершип позволит убрать из проекта EF.
Правда тут уже усть новая причина: для доступа к бд используется Linq2SQL и велосипедный мембершип позволит убрать из проекта EF.
У стандартного провайдера есть такой недостаток — нельзя удалять пользователей. Либо не использовать перманентные куки, ака галочку «запомнить меня».
Если с такими куками удаленный из базы пользователь заходит на страницу, то он входит как залогиненный, и контроллер если запросит User.IsAuthenticated, то тоже получает true. То есть мембершип в базу не лезет совсем при этом.
Мне интересно, решена ли такая проблема в этом примере.
Если с такими куками удаленный из базы пользователь заходит на страницу, то он входит как залогиненный, и контроллер если запросит User.IsAuthenticated, то тоже получает true. То есть мембершип в базу не лезет совсем при этом.
Мне интересно, решена ли такая проблема в этом примере.
Странности какие то происходят с Http модулями. Попытался сделать что то похожее, никак через web.config не получается зарегистрировать модуль. Брейкпоинтов наставил — управление сразу попадает в контроллер. При этом проект урока, который отсюда скачал — работает. Но у него свой косяк. Первый раз заходит в http модуль, потом попадает в контроллер, как и ожидается, но потом еще раз 10 управление попадает в http модуль, причем из нескольких разных потоков. На всех контроллерах наставил брейков — никуда больше управление не попадает на повторных вызовах…
Нашел в интернете, как можно подключать модули из кода, сделал у себя — работает. Причем попадает в http модуль один раз на каждый запрос, как и должно. Правда саму авторизацию я еще не реализовал, может еще всплывет что нибудь.
Нашел в интернете, как можно подключать модули из кода, сделал у себя — работает. Причем попадает в http модуль один раз на каждый запрос, как и должно. Правда саму авторизацию я еще не реализовал, может еще всплывет что нибудь.
Столкнулся с такой же проблемой. Ответ нашёл здесь: http://stackoverflow.com/questions/15768203/httpmodule-not-called-in-net-4-5
Вкратце, модуль надо подключать вот так:
Вкратце, модуль надо подключать вот так:
<system.webServer>
...
<modules>
<add name="AuthHttpModule" type="LessonProject.Global.Auth.AuthHttpModule" />
</modules>
</system.webServer>
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ASP.NET MVC Урок 6. Авторизация