HTTP-заголовок Activate-Storage-Access заголовок ответа позволяет серверу активировать предоставленное разрешение на доступ к своим неразделённым файлам cookie в межсайтовом запросе.

Сервер использует сведения о состоянии разрешения, переданные в заголовке запроса Sec-Fetch-Storage-Access.

В совокупности эти заголовки называются заголовками доступа к хранилищу. Они представляют собой эффективную альтернативу сначала загрузке ресурса без файлов cookie, затем использованию Storage Access API для активации разрешения и последующей повторной загрузке ресурса с файлами cookie.

Синтаксис

Activate-Storage-Access: retry; allowed-origin="https://foo.bar"
Activate-Storage-Access: retry; allowed-origin=*
Activate-Storage-Access: load

Директивы

retry

Сервер использует этот токен, чтобы сообщить, что для корректного ответа на запрос ему нужны сторонние файлы cookie.

Перед отправкой ответа с этим токеном серверу следует проверить наличие Sec-Fetch-Storage-Access: inactive в запросе, чтобы убедиться, что разрешение уже предоставлено (но неактивно). Чтобы разрешить доступ определённому источнику, необходимо указать параметр allowed-origin (укажите *, чтобы разрешить любой источник).

Браузер должен активировать уже предоставленное разрешение на доступ к хранилищу и повторить запрос, включив в него неразделённые файлы cookie.

load

Сервер использует этот токен, чтобы сообщить, что отправляет браузеру HTML-документ, которому необходимо активировать ранее предоставленное разрешение storage-access, чтобы получить доступ к неразделённым файлам cookie во время загрузки.

Перед отправкой ответа с load серверу следует проверить наличие в запросе Sec-Fetch-Storage-Access: inactive или Sec-Fetch-Storage-Access: active, чтобы убедиться, что разрешение уже предоставлено.

Браузер должен загрузить ресурс и предоставить ему доступ к неразделённым файлам cookie.

Описание

Storage Access API предоставляет механизм JavaScript, позволяющий встроенному ресурсу запросить разрешение storage-access. Это позволяет отправлять сторонние файлы cookie в запросах, которые в противном случае по умолчанию блокировались бы большинством браузеров. Сначала ресурс необходимо запросить без файлов cookie, чтобы сервер вернул версию ресурса без учётных данных, которая не будет иметь доступа к собственным файлам cookie. После загрузки этот ресурс может вызвать Document.requestStorageAccess() при временной активации, чтобы запросить разрешение на доступ к хранилищу. Если пользователь предоставит разрешение, браузер сохранит его в ключе, связанном с встраивающим и встроенным сайтами. Затем браузер должен перезагрузить ресурс, который теперь может отправить запрос с файлами cookie, поскольку для текущего контекста у него есть состояние разрешения active.

Разрешение предоставляется для определённой пары встраивающего и встроенного сайтов, но активируется только для определённого источника и определённого контекста, например <iframe> или вкладки браузера. Это означает, что если загрузить ту же страницу в новой вкладке или <iframe>, состояние разрешения в этом контексте будет предоставлено, но inactive; оно не станет active, пока разрешение не будет активировано. Аналогично, если загрузить другой источник на том же сайте, разрешение будет предоставлено, но его потребуется активировать, чтобы для этого ресурса отправлялись или загружались сторонние файлы cookie.

Чтобы получить разрешение на доступ к хранилищу, ресурс необходимо загрузить хотя бы один раз. Однако после предоставления разрешения сервер может использовать Activate-Storage-Access для активации разрешения для других источников и контекстов.

Это работает следующим образом:

1. Браузер добавляет Sec-Fetch-Storage-Access: inactive к запросам, когда разрешение для контекста предоставлено, но не активировано (вместе с заголовком Origin, указывающим источник запроса).
2. Если сервер получает Sec-Fetch-Storage-Access: inactive, он может ответить с помощью Activate-Storage-Access: retry; allowed-origin="<request_origin>", попросив браузер активировать разрешение для контекста и повторить запрос.
3. Если браузер получает запрос на повторную отправку, он активирует разрешение и отправляет запрос снова, на этот раз с Sec-Fetch-Storage-Access: active и включёнными файлами cookie.
4. Если сервер получает запрос с Sec-Fetch-Storage-Access: active и файлами cookie, он отвечает версией ресурса с учётными данными. После загрузки браузером этот ресурс получает доступ к своим файлам cookie так же, как ресурс первой стороны.

Ответы также должны содержать заголовок Vary со значением Sec-Fetch-Storage-Access.

Примеры

В этих примерах показаны запросы с заголовком Sec-Fetch-Storage-Access для контекстов с разными состояниями разрешения на доступ к хранилищу, а также соответствующие ответы с Activate-Storage-Access. В качестве примера используется сайт https://mysite.example, который содержит <iframe> со встроенной страницей профиля пользователя embedded.com/user/profile.

Сервер активирует разрешение

В этом примере предполагается, что пользователь уже предоставил разрешение для контекста, но оно ещё не было активировано. (При использовании API разрешение активируется перезагрузкой ресурса, чтобы он мог вызвать Document.requestStorageAccess().)

Запрос представляет собой межсайтовый <iframe> с режимом учётных данных "include". Браузер добавил Sec-Fetch-Storage-Access: inactive к запросу, поскольку разрешение secure-access было предоставлено, но не активировано. Файлы cookie не добавлены, так как по умолчанию они блокируются. Также задан Origin, поскольку серверу нужно знать источник запроса.

GET /user/profile HTTP/1.1
Host: embedded.com
Origin: https://mysite.example
Sec-Fetch-Dest: iframe
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: navigate
Sec-Fetch-Storage-Access: inactive
Credentials-Mode: include

Сервер отвечает с помощью Activate-Storage-Access: retry; allowed-origin="https://mysite.example", указывая, что браузер должен активировать предоставленное разрешение и повторить запрос с файлами cookie. Сервер включает заголовок Vary, поскольку ответ может меняться в зависимости от Sec-Fetch-Storage-Access.

HTTP/1.1 401 Unauthorized
Content-Type: text/html
Vary: Sec-Fetch-Storage-Access
Activate-Storage-Access: retry; allowed-origin="https://mysite.example"

Браузер активирует разрешение и отправляет новый запрос. Ниже видно, что он задаёт Sec-Fetch-Storage-Access: active и на этот раз включает сторонние файлы cookie.

GET /user/profile HTTP/1.1
Host: embedded.com
Origin: https://mysite.example
Sec-Fetch-Dest: iframe
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: navigate
Sec-Fetch-Storage-Access: active
Credentials-Mode: include
Cookie: sessionid=abc123

Затем сервер отвечает ресурсом с учётными данными, содержащим Activate-Storage-Access: load. Ресурс загружается и получает доступ к своим файлам cookie так же, как встроенный ресурс первой стороны.

HTTP/1.1 200 OK
Content-Type: text/html
Activate-Storage-Access: load
Vary: Sec-Fetch-Storage-Access

<html>
  ...
</html>

Разрешение secure-access изначально не предоставлено

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

Заголовки могут активировать разрешение только для контекста, которому оно уже предоставлено, — их нельзя использовать, чтобы изначально предоставить разрешение на доступ к хранилищу. Поэтому встроенную страницу необходимо загрузить без файлов cookie, а затем вызвать Document.requestStorageAccess() при временной активации, чтобы запросить разрешение на доступ к хранилищу. Этот процесс не отличается от ситуации, когда заголовки отсутствуют.

Запрос такой же, как в предыдущем примере, за исключением того, что браузер добавил Sec-Fetch-Storage-Access: none, поскольку разрешение secure-access не предоставлено. Файлы cookie также не добавлены, поскольку по умолчанию они блокируются.

GET /user/profile HTTP/1.1
Host: embedded.com
Origin: https://mysite.example
Sec-Fetch-Dest: iframe
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: navigate
Sec-Fetch-Storage-Access: none
Credentials-Mode: include

Сервер возвращает версию ресурса без учётных данных. В неё включён заголовок Vary, поскольку ответ может меняться в зависимости от Sec-Fetch-Storage-Access. Обратите внимание, что Activate-Storage-Access не включён, так как сервер не может активировать разрешение, если оно не было предоставлено.

HTTP/1.1 200 OK
Content-Type: text/html
Vary: Sec-Fetch-Storage-Access

<html>
  ...
</html>

Затем встроенная страница вызовет Document.requestStorageAccess() при временной активации, чтобы запросить разрешение на доступ к хранилищу. Если разрешение на доступ к хранилищу предоставлено для встроенной страницы, оно также активируется.

Затем страница перезагрузится, что приведёт к следующему запросу. На этот раз браузер добавляет Sec-Fetch-Storage-Access: active и включает сторонние файлы cookie, отражая состояние разрешения для встроенного содержимого.

GET /user/profile HTTP/1.1
Host: embedded.com
Origin: https://mysite.example
Sec-Fetch-Dest: iframe
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: navigate
Sec-Fetch-Storage-Access: active
Credentials-Mode: include
Cookie: sessionid=abc123

Сервер отвечает версией ресурса с учётными данными, которая может отличаться от первой загруженной версии, и добавляет заголовок Activate-Storage-Access: load. Браузер загружает страницу, которая теперь получает доступ к собственным файлам cookie.

HTTP/1.1 200 OK
Content-Type: text/html
Vary: Sec-Fetch-Storage-Access
Activate-Storage-Access: load

<html>
  ...
</html>

Спецификации

Совместимость с браузерами

См. также

• Sec-Fetch-Storage-Access
• Заголовки доступа к хранилищу в Storage Access API
• Последовательности заголовков доступа к хранилищу в Storage Access API