Проверка авторизации для HTTP-кешей

Question

У меня есть метод Web API, как указано ниже, для службы REST. Это делается для получения всей информации о пользователях InventoryAuditors. Доступ к этому ресурсу могут получить только авторизованные пользователи InventoryAuditor.

[RoutePrefix("api/users")] 
public class UsersController : ApiController 
{ 
    [Authorize(Roles="InventoryAuditor")] 
    [Route("")] 
    [HttpGet] 
    public List<User> GetAllUsers() 
    { 
     //Return list of users 
    } 

} 

public class User 
{ 
    public int UserID { get; set; } 
    public string FirstName { get; set; } 
} 

Вопросы

1. Является ли этот ресурс кэшируется для shared caches (как Forward Proxies и другие промежуточные кэши)?
2. Если да, то как общий кэш выполняет проверку авторизации - как кеш знает, что ресурс должен обслуживаться только для InventoryAuditors?
3. Как заголовки должны выглядеть так, чтобы это разрешенное представление было кэшируемым?

or is HTTP Caching Не все должны использоваться в случае авторизованных ресурсов?

Примечание: В статье "Caching Tutorial for Web Authors and Webmasters" говорит:

По умолчанию, страница, защищенная аутентификация HTTP считаются частной; они не будут храниться в общих кэшах. Тем не менее, вы можете публиковать открытые страницы с открытым заголовком Cache-Control: public; HTTP-совместимые кеши будут затем кэшироваться.

ЛИТЕРАТУРА

1. https://tools.ietf.org/html/rfc7235#section-4.2
2. https://tools.ietf.org/html/rfc7234#section-3.2
3. https://tools.ietf.org/html/rfc7234#section-5.2.2
4. Hypertext Transfer Protocol (HTTP/1.1): Caching
5. Feature: Bearer Authentication- Squid
6. Stupid Web Caching Tricks

Answer 1

То, что я понял из чтения различных ресурсов является -. Следующие заголовки могут помочь в кэширование разрешенных ресурсов.

Cache-Control: public, max-age=0

1. Max-Age = 0: Требуется кэш перепроверить с сервером, используя запрос условный GET. При повторной аттестации с сервером заголовки авторизации будут отправлены на сервер.
2. Максимальный возраст = 0 отличается от обязательной проверки. Максимальный возраст = 0 позволяет кэшировать ответы , содержащие также заголовки авторизации.

относятся также

1. Rest in Practice - REST+caching+authorize

2. Web Caching - Authentication

Answer 2

По этой ссылке вы предоставили

В частности, ответ с либо "MaxAge = 0, нужно обязательно перепроверять" или "s-MaxAge = 0" не может быть использован для удовлетворения последующий запрос без повторной проверки его на исходном сервере.

Переднее веб-прокси должен иметь возможность исследовать заголовок Cache-Control ответа, чтобы определить будет ли кабина используется для сервера последующих запросов

Простой тест показал, что ответы на санкционированных запросов в осины. нетто имеют следующий набор заголовков:

Cache-Control: частный, втор-MaxAge = 0

Это в соответствии с протоколом, как ответ ча ching фактически обрабатывается, зависит от используемого вами веб-сервера.

UPDATE

1) Является ли этот ресурс кэшируется для общих кэшей (как Форвард Proxies и других промежуточных кэша)?

NO

"Cache-контроль:. Частный Указывает, что все или часть ответного сообщения предназначена для одного пользователя и НЕ ДОЛЖНЫ быть кэшируются общий кэш Это позволяет , чтобы указать, что указанные части ответа предназначены только для одного пользователя и не являются допустимым ответом на запросы других пользователей. Частный (не общий) кэш МОЖЕТ кэшировать ответ. * «

https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1

2) Если да, то как же общий кэш выполняет проверку авторизации - как же кэш знать, что ресурс должен быть подан только для InventoryAuditors?

Н.А.

3) Каковы различные подходы для достижения кэширования такого санкционированного содержания в общих кэшей?

Вы можете программно установить заголовки на все, что вы хотите, чтобы манипулировать поведением кэширования общих прокси

прокси-перепроверить директива прокси-REVALIDATE имеет тот же смысл, что и директива MUST- перепроверить, за исключением того, что он не применяется к кэшам пользователей, не являющихся общими ,. Он может использоваться для ответа на аутентифицированный запрос , чтобы позволить кэшу пользователя хранить и затем возвращать ответ , не требуя его повторной проверки (поскольку он уже был указан , который был аутентифицирован один раз этим пользователем), , все еще требуя прокси, которые сервисное обслуживание многих пользователей каждый раз, когда (чтобы убедиться, что каждый пользователь аутентифицирован). Обратите внимание, что такие аутентифицированные ответы также должны директивы управления общественного кэша для того, чтобы позволить им кэшировать на всех * https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4