Авторизация и ASP.NET MVC Кэширование

Question

Я запутался в кэшировании и авторизации 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. Помощь?

Answer 1

Есть два отдельных вопроса:

<Ол>

Аутентификация работает с кэшированием в MVC?

Работает ли Session до аутентификации в кеше (даже для неаутентифицированных пользователей, у которых все еще есть надежда на уникальную сессию)?

Ответы, соответственно, да и нет. Аутентификация отлично работает с кешированием. Попробуйте это с поставщиками членства SQL или Domain; вы увидите.

Кэширование, однако, может выполняться до модуля аутентификации. (Для бонусных баллов: почему?) Аутентификация вызывается, только если она специально перехватывает кеш (как это делает AuthorizeAttribute). Поскольку сессии зависят от пользователя, нет гарантии, что у вас будет сеанс внутри AuthorizeCore.

Дополнительные бонусные баллы: как это могло бы измениться, если вы указали в настройке кэша переменную VarByUser?

К сожалению, сделать право аутентификации сложно, потому что сложно реализовать любое право защиты. Microsoft пытается сделать это проще с помощью API поставщика членства. Я настоятельно рекомендую использовать это при реализации пользовательской аутентификации. Я также рекомендую использовать встроенные провайдеры и расширять их, а не переписывать, когда это возможно.

Еще один момент: поставщик сеансов ASP.NET и поставщик членства в ASP.NET полностью разделены. Разные пользователи могут делиться (!) Сессией и, да , вы можете атаковать сайт таким образом. никогда безопасно помещать информацию о безопасности в сеанс. Безопасность это сложно.