Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 17
HTTP модули запускаются раньше в цепочке прохождения запроса. Если проводите аутентификацию в обработчике сообщений, контекст безопасности не будет установлен пока не будет запущен обработчик. Кроме того, контекст безопасности возвращается к предыдущему состоянию когда ответ на запрос покинет обработчик сообщения.
Это каким же образом контекст безопасности вернется к предыдущему состоянию?
Вообще уже давно пора рассказывать про OWIN и забыть про модули и хэндлеры из Asp.Net. Делать аутентификацию через MessageHandler я бы то же не стал, так как есть OWIN Authentication Middleware, который позволяет сделать централизованный механизм аутентификации для всех вызовов независимо от используемого в дальнейшем фрэймфорка.
OWIN Authentication Middleware, который позволяет сделать централизованный механизм аутентификации для всех вызовов независимо от используемого в дальнейшем фрэймфорка.
Как централизированный механизм это не работает пока вообще. В ASP.NET стеке вчистую это будет работать только с SignalR или WebApi и то под 4.5 фреймворком, в продуктивных системах я думаю это не больше 5-10% от всех коммерческих ASP.NET приложений в лучшем случае. Но это сугубо мое мнение.
На текущий момент даже совместимые Owin технологии практически всегда применяются в связке с зависимыми от System.Web технологиями, что автоматически делает более вероятным использование, именно HttpModules и уже в качестве адаптера для Owin компонентов Microsoft.Owin.SystemWeb(Katana). Поэтому аутентификация до сих пор практически всегда будет реализована на базе модулей. Даже для OWIN совместимой части стека.
Интеграция 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
Интеграция OWIN работает отлично со всеми фреймворками. Да, для MVC требуется пока что интеграция OWIN с System.Web, но работает он отлично и позволяет по максимуму исключить модули.
Работает оно правильно только если вы используете Katana компоненты для всего и явно или неявно(если поставщик модуля учитывает наличие IIS) превращаете ваше middleware в http модули. Если вы это не делаете, или используете компоненты, которые этого не учитывают, оно работает неправильно, причем еще и без явных ошибок, для разработчика, который не понимает, как надо верное owin midleware использовать в связке с IIS Integrated pipe.
Ради интереса попробуйте сделать аутентификацию через OAuth2 и WS-Federation через модули на одном хосте.
И какие сложности возникли у вас при этом, которых удалось избежать при использовании OWIN для MVC.
1. WebHost и вперед. WebApi не зареганый как модуль отлично работает. В любом случае — это предпочительный вариант в свете Asp.Net vNext.
2. Отдайте 401 статус код и посмотрите какой из модулей его обработает и как.
Повторюсь, на данный момент в свете Asp.Net vNext инвестировать время в разработку HttpModules не эффективно. Если вложить ресурсы в развитие базы кода с использованием OWIN — То это будет гораздо эффективнее(и возможно даже кроссплатформенней) и не придется выкидывать код или кардинально его переделывать.
2. Отдайте 401 статус код и посмотрите какой из модулей его обработает и как.
Повторюсь, на данный момент в свете Asp.Net vNext инвестировать время в разработку HttpModules не эффективно. Если вложить ресурсы в развитие базы кода с использованием OWIN — То это будет гораздо эффективнее(и возможно даже кроссплатформенней) и не придется выкидывать код или кардинально его переделывать.
Я не совсем понял к чему эти пункты.
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, все это нельзя будет назвать «Отлично работает со всеми фреймворками и универсальная для всего.»
Вы кстати, наверное до сих пор не поняли о чем речь. Думаю полезно будет: 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.
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 будет слабым звеном в пуле авторизации?
Я отвечу дальше.
Можно задам встречный вопрос, что бы знать хоть бы понимаете ли вы суть ссылок которые привели и контраргументов, которые здесь малоуместны.
Если вы закинули ваше Owin приложение в IIS поверх Katana, в какой момент IIS передаст управление этому OWIN приложению, когда пришел http запрос на сервер?
Можно задам встречный вопрос, что бы знать хоть бы понимаете ли вы суть ссылок которые привели и контраргументов, которые здесь малоуместны.
Если вы закинули ваше Owin приложение в IIS поверх Katana, в какой момент IIS передаст управление этому OWIN приложению, когда пришел http запрос на сервер?
Могу даже варианты выбора предложить:
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
ЭЭ вы чего? Какая дыра в безопасности то с MVC?
Даже если технология не полностью «совместима»(то есть просит System.Web) — работает на отлично. Просто сделали интеграцию с OWIN через HttpModule. В результате все отлично работает. Где вы нашли проблему — не пойму. Хотите — настройте в каком ивенте вам обрабатывать.
Пока я не вижу ни одного аргумента в сторону старых HttpModule's.
Даже если технология не полностью «совместима»(то есть просит System.Web) — работает на отлично. Просто сделали интеграцию с OWIN через HttpModule. В результате все отлично работает. Где вы нашли проблему — не пойму. Хотите — настройте в каком ивенте вам обрабатывать.
Пока я не вижу ни одного аргумента в сторону старых HttpModule's.
Пока я не вижу ни одного аргумента в сторону старых HttpModule's.
А что я должен аргументировать? Я где-то писал что http module, лучше чем middleware, что вы от меня ждете аргументов? :)
Где вы нашли проблему — не пойму
Да я и не искал проблем.
Вы написали, надо использовать универсальный owin и вообще забыть про http modules и handlers из классического asp.net.
Я ответил, что это не совсем так. До сих пор ASP.NET стек можно подружить с middleware только используя реализацию owin от microsoft — Katana, которая все равно имеет дело с http application events и модулями. И если не использовать специфичекую конфигурацию, middleware могут работать неправильно.
Ну мой посыл заключался в том, что на данный момент развивать идею модулей — не логично, в силу текущей конъюнктуры. Для текущих проектов это не особо актуально ИМХО, а вот для новых вполне. Там и 4.5+ весьма вероятен и цепляться на старые модули нет смысла.
Интеграция с System.Web выполнена в виде HttpModule, но чего-то страшного я здесь не вижу. В последствие можно будет легко убрать этот интеграционный слой и не трогать всю остальную логику. Дефолтные шаблоны приложений дают вполне вменяемый базовый каркас с OWIN MIddleware. Все что нужно — поставить WebHost.
Интеграция с System.Web выполнена в виде HttpModule, но чего-то страшного я здесь не вижу. В последствие можно будет легко убрать этот интеграционный слой и не трогать всю остальную логику. Дефолтные шаблоны приложений дают вполне вменяемый базовый каркас с OWIN MIddleware. Все что нужно — поставить WebHost.
К OWIN дальше и хочу перейти. Сам использую именно его.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Аутентификация и авторизация в ASP.NET Web API