Кто-то может объяснить этот блок ASP.NET код MVC мне?
это - текущий код в ASP.NET MVC2 (RTM) System.Web.Mvc.AuthorizeAttribute класс:-
public virtual void OnAuthorization(AuthorizationContext filterContext)
{
if (filterContext == null)
{
throw new ArgumentNullException("filterContext");
}
if (this.AuthorizeCore(filterContext.HttpContext))
{
HttpCachePolicyBase cache = filterContext.HttpContext.Response.Cache;
cache.SetProxyMaxAge(new TimeSpan(0L));
cache.AddValidationCallback(
new HttpCacheValidateHandler(this.CacheValidateHandler), null);
}
else
{
filterContext.Result = new HttpUnauthorizedResult();
}
}
таким образом, если я 'авторизовываюсь', затем делают некоторый кэширующийся материал, иначе бросают 401 Несанкционированный ответ.
Вопрос: Что те 3 строки кэширования делает?
аплодисменты :)
2 ответа
Этот код существует, чтобы вы могли объединить [OutputCache] и [Authorize] в действие, не рискуя получить ответ, который был сгенерирован для авторизованного пользователя, кэширован и передан пользователю, который не авторизован.
Вот комментарий исходного кода из AuthorizeAttribute.cs:
Поскольку мы выполняем авторизацию на уровне действия авторизация код запускается после кэширования вывода модуль. В худшем случае это могло разрешить авторизованному пользователю вызвать страницу для кеширования, затем неавторизованный пользователь позже будет обслуживает кешированную страницу. Мы работаем это путем указания прокси не кэшировать чувствительную страницу, затем мы подключаем пользовательский код авторизации в механизм кэширования, чтобы у нас был последнее слово о том, должна ли страница быть обслуживается из кеша.
Так что же делает этот атрибут? Сначала он отключает прокси-кеширование этого ответа, поскольку прокси-серверы не могут правильно определить, какие пользователи имеют или не авторизованы для его просмотра. И если прокси обслуживает ответ неавторизованному пользователю, это очень плохо.
А что насчет AddValidationCallback? В ASP.NET модуль кэширования вывода перехватывает события, которые выполняются до обработчика HTTP.Поскольку MVC на самом деле является просто специальным обработчиком HTTP, это означает, что если модуль кэширования вывода обнаруживает, что этот ответ уже был кэширован, модуль просто будет обслуживать ответ непосредственно из кеша, вообще не проходя через конвейер MVC. Это также потенциально очень плохо, если кэш вывода обслуживает ответ неавторизованному пользователю.
Теперь внимательно рассмотрим CacheValidateHandler :
private void CacheValidateHandler(HttpContext context, object data, ref HttpValidationStatus validationStatus) {
validationStatus = OnCacheAuthorization(new HttpContextWrapper(context));
}
// This method must be thread-safe since it is called by the caching module.
protected virtual HttpValidationStatus OnCacheAuthorization(HttpContextBase httpContext) {
if (httpContext == null) {
throw new ArgumentNullException("httpContext");
}
bool isAuthorized = AuthorizeCore(httpContext);
return (isAuthorized) ? HttpValidationStatus.Valid : HttpValidationStatus.IgnoreThisRequest;
}
Фактически это просто связывает метод AuthorizeCore с кешированным ответом. Когда модуль кэша вывода обнаруживает совпадение, он повторно запускает метод AuthorizeCore, чтобы убедиться, что текущему пользователю действительно разрешено видеть кэшированный ответ. Если AuthorizeCore возвращает true, это рассматривается как попадание в кеш (HttpValidationStatus.Valid), и ответ подается из кеша без прохождения конвейера MVC. Если AuthorizeCore возвращает false, это рассматривается как промах в кэше (HttpValidationStatus.IgnoreThisRequest), и конвейер MVC запускается в обычном режиме для генерации ответа.
В стороне, поскольку делегат формируется для AuthorizeCore (таким образом, фиксируется конкретный экземпляр AuthorizeAttribute) и сохраняется в статическом кэше, поэтому все типы, подклассы AuthorizeAttribute, должны быть потокобезопасными.
вызов AuthorizeCore проверяет, авторизован ли запрос. Если запрос авторизован, он помещает AddValidationCallback, чтобы проверить, действителен ли кэшированный вывод в соответствии с политикой кэширования. Если да, то кэшированный вывод отправляется клиенту.
Что касается 3 строк для кэширования; во-первых, вы должны понимать, что кэш вывода должен быть корректным или настолько корректным, насколько это возможно. Чтобы оценить его "правильность", система будет проверять, удовлетворяет ли он определенным условиям (например, не был ли он изменен). Это можно сделать в 3 строке...