Авторизация и ASP.NET MVC Кэширование
-
10-07-2019 - |
Вопрос
Я запутался в кэшировании и авторизации ASP.NET MVC и остро нуждается в некоторых пояснениях.
Мой самодельный атрибут авторизации наследуется от AuthorizeAttribute
. Его переопределенный метод AuthorizeCore
запускается каждый раз, даже если я установил атрибут [OutputCache]
для действия контроллера. Я понимаю эту часть.
Теперь для меня это не из легких: AuthorizeCore
будет давать сбой каждый раз, когда я действительно выполняю кэширование вывода, и страница обслуживается из кэша. Причина заключается в том, что при кэшировании запроса httpContext.Session
, поставляемый с AuthorizeCore
, становится null
!? Вот несколько упрощенных кодов:
protected override bool AuthorizeCore(HttpContextBase httpContext) {
return (Session["userId"] != null)
}
Итак, если httpContext.Session
равен null
, это, очевидно, каждый раз приводит к сбою. Мне нужен доступ к сеансу, но как еще можно проверить, авторизован ли запрос? Это не имеет никакого смысла - если это так, то я бы никогда не смог использовать кэшированные страницы вместе с аутентификацией в ASP.NET MVC. Помощь?
Решение
Есть два отдельных вопроса:
<Ол>Ответы, соответственно, да и нет. Аутентификация отлично работает с кешированием. Попробуйте это с поставщиками членства SQL или Domain; вы увидите.
Кэширование, однако, может выполняться до модуля аутентификации. (Для бонусных баллов: почему?) Аутентификация вызывается, только если она специально перехватывает кеш (как это делает AuthorizeAttribute). Поскольку сессии зависят от пользователя, нет гарантии, что у вас будет сеанс внутри AuthorizeCore.
Дополнительные бонусные баллы: как это могло бы измениться, если вы указали в настройке кэша переменную VarByUser?
К сожалению, сделать право аутентификации сложно, потому что сложно реализовать любое право защиты. Microsoft пытается сделать это проще с помощью API поставщика членства. Я настоятельно рекомендую использовать это при реализации пользовательской аутентификации. Я также рекомендую использовать встроенные провайдеры и расширять их, а не переписывать, когда это возможно. Р>
Еще один момент: поставщик сеансов ASP.NET и поставщик членства в ASP.NET полностью разделены. Разные пользователи могут делиться (!) Сессией и, да , вы можете атаковать сайт таким образом. никогда безопасно помещать информацию о безопасности в сеанс. Безопасность это сложно.