Comments 17
HTTP модули запускаются раньше в цепочке прохождения запроса. Если проводите аутентификацию в обработчике сообщений, контекст безопасности не будет установлен пока не будет запущен обработчик. Кроме того, контекст безопасности возвращается к предыдущему состоянию когда ответ на запрос покинет обработчик сообщения.
Это каким же образом контекст безопасности вернется к предыдущему состоянию?
0
Вообще уже давно пора рассказывать про OWIN и забыть про модули и хэндлеры из Asp.Net. Делать аутентификацию через MessageHandler я бы то же не стал, так как есть OWIN Authentication Middleware, который позволяет сделать централизованный механизм аутентификации для всех вызовов независимо от используемого в дальнейшем фрэймфорка.
+1
OWIN Authentication Middleware, который позволяет сделать централизованный механизм аутентификации для всех вызовов независимо от используемого в дальнейшем фрэймфорка.
Как централизированный механизм это не работает пока вообще. В ASP.NET стеке вчистую это будет работать только с SignalR или WebApi и то под 4.5 фреймворком, в продуктивных системах я думаю это не больше 5-10% от всех коммерческих ASP.NET приложений в лучшем случае. Но это сугубо мое мнение.
На текущий момент даже совместимые Owin технологии практически всегда применяются в связке с зависимыми от System.Web технологиями, что автоматически делает более вероятным использование, именно HttpModules и уже в качестве адаптера для Owin компонентов Microsoft.Owin.SystemWeb(Katana). Поэтому аутентификация до сих пор практически всегда будет реализована на базе модулей. Даже для OWIN совместимой части стека.
+1
Интеграция OWIN работает отлично со всеми фреймворками. Да, для MVC требуется пока что интеграция OWIN с System.Web, но работает он отлично и позволяет по максимуму исключить модули. Вообще в проде уже достаточно софта на 4.5. Ради интереса попробуйте сделать аутентификацию через OAuth2 и WS-Federation через модули на одном хосте.
Самое главное — вы через полгода-год будете опять все переписывать? Зачем сейчас на это закладываться? Ведь если народ выбирает способ аутентификации — то проект в самом начале(скорее всего), а это значит есть возможность использовать 4.5+(нет смысла не делать этого — 2003 серваков я на проде уже года 3 не видел).
Вот прямо сейчас смотрю на проект в котором используются OWIN Authentication Middleware для аутентификации в MVC, WebApi и SignalR. Все HttpModule's были выпилены из проекта. В middleware еще и централизованое логирование, поддержка IoC, детерменированность порядка выполнения как минимум.
А в целом рекомендую начать знакомство с thinktecture@github
Самое главное — вы через полгода-год будете опять все переписывать? Зачем сейчас на это закладываться? Ведь если народ выбирает способ аутентификации — то проект в самом начале(скорее всего), а это значит есть возможность использовать 4.5+(нет смысла не делать этого — 2003 серваков я на проде уже года 3 не видел).
Вот прямо сейчас смотрю на проект в котором используются OWIN Authentication Middleware для аутентификации в MVC, WebApi и SignalR. Все HttpModule's были выпилены из проекта. В middleware еще и централизованое логирование, поддержка IoC, детерменированность порядка выполнения как минимум.
А в целом рекомендую начать знакомство с thinktecture@github
+1
Интеграция OWIN работает отлично со всеми фреймворками. Да, для MVC требуется пока что интеграция OWIN с System.Web, но работает он отлично и позволяет по максимуму исключить модули.
Работает оно правильно только если вы используете Katana компоненты для всего и явно или неявно(если поставщик модуля учитывает наличие IIS) превращаете ваше middleware в http модули. Если вы это не делаете, или используете компоненты, которые этого не учитывают, оно работает неправильно, причем еще и без явных ошибок, для разработчика, который не понимает, как надо верное owin midleware использовать в связке с IIS Integrated pipe.
Ради интереса попробуйте сделать аутентификацию через OAuth2 и WS-Federation через модули на одном хосте.
И какие сложности возникли у вас при этом, которых удалось избежать при использовании OWIN для MVC.
0
1. WebHost и вперед. WebApi не зареганый как модуль отлично работает. В любом случае — это предпочительный вариант в свете Asp.Net vNext.
2. Отдайте 401 статус код и посмотрите какой из модулей его обработает и как.
Повторюсь, на данный момент в свете Asp.Net vNext инвестировать время в разработку HttpModules не эффективно. Если вложить ресурсы в развитие базы кода с использованием OWIN — То это будет гораздо эффективнее(и возможно даже кроссплатформенней) и не придется выкидывать код или кардинально его переделывать.
2. Отдайте 401 статус код и посмотрите какой из модулей его обработает и как.
Повторюсь, на данный момент в свете Asp.Net vNext инвестировать время в разработку HttpModules не эффективно. Если вложить ресурсы в развитие базы кода с использованием OWIN — То это будет гораздо эффективнее(и возможно даже кроссплатформенней) и не придется выкидывать код или кардинально его переделывать.
0
Я не совсем понял к чему эти пункты.
1. Да, работает, и так и так внутри абсолютно одинаково.
2. Могу предположить, что не один из интересующих нас, потому что когда хендлер обработал запрос, то последующие события сязанные с обновлением Кеша и отправкой http ответа модули http аутентификации должны мало интересовать.
Я не спорю, что будущее за OWIN. Но пока основная веб-технология в стеке ASP.NET не Owin совместима, а Helios в нестабильной alphe и так же не совместим с MVC + Большинство разработчиков, которые хостят под IIS Owin приложение, даже не знают на каком событии httapplication будут вызваны middleware, все это нельзя будет назвать «Отлично работает со всеми фреймворками и универсальная для всего.»
1. Да, работает, и так и так внутри абсолютно одинаково.
2. Могу предположить, что не один из интересующих нас, потому что когда хендлер обработал запрос, то последующие события сязанные с обновлением Кеша и отправкой http ответа модули http аутентификации должны мало интересовать.
Я не спорю, что будущее за OWIN. Но пока основная веб-технология в стеке ASP.NET не Owin совместима, а Helios в нестабильной alphe и так же не совместим с MVC + Большинство разработчиков, которые хостят под IIS Owin приложение, даже не знают на каком событии httapplication будут вызваны middleware, все это нельзя будет назвать «Отлично работает со всеми фреймворками и универсальная для всего.»
0
Вы кстати, наверное до сих пор не поняли о чем речь. Думаю полезно будет: www.asp.net/aspnet/overview/owin-and-katana/owin-middleware-in-the-iis-integrated-pipeline.
Если вы взяли какой-то OWIN Authentication Middleware, который этого не учитывает и вдруг решили использовать вместе с MVC, то у вас потенциально появиться здоровенная дыра в безопасности.
OWIN универсальный интерфейс, только для технологий совместимых с ним. ASP.NET MVC, WebForms, WebPages в этот список не входят.
MS самой собой дали инструмент, не имея возможности сделать System.Web совместимым с OWIN, просто наделали кучу костылей, что бы оно завелось с system.web.
Если вы взяли какой-то OWIN Authentication Middleware, который этого не учитывает и вдруг решили использовать вместе с MVC, то у вас потенциально появиться здоровенная дыра в безопасности.
OWIN универсальный интерфейс, только для технологий совместимых с ним. ASP.NET MVC, WebForms, WebPages в этот список не входят.
MS самой собой дали инструмент, не имея возможности сделать System.Web совместимым с OWIN, просто наделали кучу костылей, что бы оно завелось с system.web.
0
ASP.NET MVC, WebForms в этот список не входят.
Все отлично заводится на раз-два с OWIN. Думаю полезно будет: www.asp.net/mvc/tutorials/mvc-5/create-an-aspnet-mvc-5-app-with-facebook-and-google-oauth2-and-openid-sign-on
PS: О какой дыре в безопасности речь? Честно, назовите хотя бы один единственный сценарий при котором именно OWin middleware будет слабым звеном в пуле авторизации?
Все отлично заводится на раз-два с OWIN. Думаю полезно будет: www.asp.net/mvc/tutorials/mvc-5/create-an-aspnet-mvc-5-app-with-facebook-and-google-oauth2-and-openid-sign-on
PS: О какой дыре в безопасности речь? Честно, назовите хотя бы один единственный сценарий при котором именно OWin middleware будет слабым звеном в пуле авторизации?
+1
Я отвечу дальше.
Можно задам встречный вопрос, что бы знать хоть бы понимаете ли вы суть ссылок которые привели и контраргументов, которые здесь малоуместны.
Если вы закинули ваше Owin приложение в IIS поверх Katana, в какой момент IIS передаст управление этому OWIN приложению, когда пришел http запрос на сервер?
Можно задам встречный вопрос, что бы знать хоть бы понимаете ли вы суть ссылок которые привели и контраргументов, которые здесь малоуместны.
Если вы закинули ваше Owin приложение в IIS поверх Katana, в какой момент IIS передаст управление этому OWIN приложению, когда пришел http запрос на сервер?
0
Могу даже варианты выбора предложить:
msdn.microsoft.com/en-us/library/system.web.httpapplication_events(v=vs.110).aspx
msdn.microsoft.com/en-us/library/system.web.httpapplication_events(v=vs.110).aspx
0
ЭЭ вы чего? Какая дыра в безопасности то с MVC?
Даже если технология не полностью «совместима»(то есть просит System.Web) — работает на отлично. Просто сделали интеграцию с OWIN через HttpModule. В результате все отлично работает. Где вы нашли проблему — не пойму. Хотите — настройте в каком ивенте вам обрабатывать.
Пока я не вижу ни одного аргумента в сторону старых HttpModule's.
Даже если технология не полностью «совместима»(то есть просит System.Web) — работает на отлично. Просто сделали интеграцию с OWIN через HttpModule. В результате все отлично работает. Где вы нашли проблему — не пойму. Хотите — настройте в каком ивенте вам обрабатывать.
Пока я не вижу ни одного аргумента в сторону старых HttpModule's.
0
Пока я не вижу ни одного аргумента в сторону старых HttpModule's.
А что я должен аргументировать? Я где-то писал что http module, лучше чем middleware, что вы от меня ждете аргументов? :)
Где вы нашли проблему — не пойму
Да я и не искал проблем.
Вы написали, надо использовать универсальный owin и вообще забыть про http modules и handlers из классического asp.net.
Я ответил, что это не совсем так. До сих пор ASP.NET стек можно подружить с middleware только используя реализацию owin от microsoft — Katana, которая все равно имеет дело с http application events и модулями. И если не использовать специфичекую конфигурацию, middleware могут работать неправильно.
0
Ну мой посыл заключался в том, что на данный момент развивать идею модулей — не логично, в силу текущей конъюнктуры. Для текущих проектов это не особо актуально ИМХО, а вот для новых вполне. Там и 4.5+ весьма вероятен и цепляться на старые модули нет смысла.
Интеграция с System.Web выполнена в виде HttpModule, но чего-то страшного я здесь не вижу. В последствие можно будет легко убрать этот интеграционный слой и не трогать всю остальную логику. Дефолтные шаблоны приложений дают вполне вменяемый базовый каркас с OWIN MIddleware. Все что нужно — поставить WebHost.
Интеграция с System.Web выполнена в виде HttpModule, но чего-то страшного я здесь не вижу. В последствие можно будет легко убрать этот интеграционный слой и не трогать всю остальную логику. Дефолтные шаблоны приложений дают вполне вменяемый базовый каркас с OWIN MIddleware. Все что нужно — поставить WebHost.
0
К OWIN дальше и хочу перейти. Сам использую именно его.
0
UFO just landed and posted this here
Sign up to leave a comment.
Аутентификация и авторизация в ASP.NET Web API