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

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

6 голосов
/ 18 сентября 2009

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

1 Ответ

12 голосов
/ 18 сентября 2009

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

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

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

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

Больше бонусных баллов: Как это могло бы измениться, если вы указали в конфигурации кеша varByUser?

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

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

...