Эта страница переведена с помощью Cloud Translation API.

Пробная версия Origin для поддержки HTTP-заголовков в Storage Access

Natalia Markoborodova

Chrome начинает пробную версию Origin для добавления заголовков HTTP в Storage Access API (SAA) в версии 130: Storage Access Headers . Новые заголовки запроса Sec-Fetch-Storage-Access и ответного заголовка Activate-Storage-Access направлены на поддержку ресурсов, отличных от iframe, а также на повышение производительности и удобства для пользователей веб-сайтов, которые используют встроенный контент, такой как виджеты социальных сетей, календари и интерактивные инструменты.

Поток JavaScript (и его ограничения)

Ранее SAA требовал вызова JavaScript API для document.requestStorageAccess() при каждой перезагрузке, даже если пользователь уже предоставил разрешение. Несмотря на свою эффективность, этот метод вводит ограничения:

Многочисленные сетевые циклы передачи данных: процесс часто включал несколько сетевых запросов и перезагрузок страниц, прежде чем встроенный контент мог полноценно функционировать.
Зависимость от iframe: выполнение JavaScript требовало использования iframe или подресурсов внутри iframe, что ограничивало гибкость для разработчиков.

Например, виджет календаря из calendar.example , встроенный в website.example с использованием только JavaScript, будет выглядеть следующим образом:

Загрузите заполнитель: website.example запрашивает виджет. Поскольку виджет calendar.example , встроенный в website.example , не имеет доступа к своим неразделенным куки, вместо него отображается виджет-заполнитель.
Запрос разрешения: загружается заполнитель, затем вызывается document.requestStorageAccess() для запроса разрешения storage-access .
Пользователь решает предоставить разрешение .
Перезагрузите виджет: виджет обновится, на этот раз с доступом к cookie-файлам, и, наконец, загрузит персонализированный контент.
Каждый раз, когда пользователь снова посещает сайт, на котором встроен виджет calendar.example , процесс выглядит точно так же, как на шагах 1, 2 и 4 ; единственное упрощение заключается в том, что пользователю не нужно повторно предоставлять доступ.

Этот процесс неэффективен: если пользователь уже предоставил разрешение на хранение, первоначальная загрузка iframe, вызов document.requestStorageAccess() и последующая перезагрузка становятся ненужными и создают задержку.

Новый поток с HTTP-заголовками

Новые заголовки доступа к хранилищу обеспечивают более эффективную загрузку встроенного контента, включая ресурсы, не являющиеся iframe.

С помощью заголовков доступа к хранилищу браузер автоматически извлечет ресурсы с установленным заголовком запроса Sec-Fetch-Storage-Access: inactive , если пользователь уже предоставил разрешение. Для установки заголовка запроса не требуется никаких действий разработчика. Сервер может ответить заголовком Activate-Storage-Access: retry; allowed-origin="<origin>" , и браузер повторит запрос с необходимыми учетными данными.

Заголовок запроса

Sec-Fetch-Storage-Access: <access-status>

Когда пользователь посещает страницу, которая встраивает межсайтовый контент, браузер автоматически включает заголовок Sec-Fetch-Storage-Access в межсайтовые запросы, которые могут требовать учетные данные (например, файлы cookie). Этот заголовок указывает статус разрешения на доступ к файлам cookie встроенного контента. Вот как интерпретировать его значения:

none : у встраиваемого объекта нет разрешения storage-access , и, следовательно, у него нет доступа к неразделенным файлам cookie.
inactive : у вставки есть разрешение storage-access , но она не решила его использовать. У вставки нет доступа к неразделенным файлам cookie.
active : у вставки есть неразделенный доступ к cookie. Это значение будет включено в любые запросы к кросс-источникам, которые имеют доступ к неразделенным cookie.

Заголовки ответа

Activate-Storage-Access: <retry-or-reload>

Заголовок Activate-Storage-Access указывает браузеру либо повторить запрос с куки, либо загрузить ресурс напрямую с активированным SAA. Заголовок может иметь следующие значения:

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

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

Поддержка ресурсов, отличных от iframe

Обновление Storage Access Headers включает SAA для не-iframe встроенного контента, например, изображений, размещенных на другом домене. Ранее ни один API веб-платформы не позволял загружать такие ресурсы с учетными данными в браузерах, если сторонние файлы cookie недоступны. Например, ваш embedding-site.example может запросить изображение:

   <img src="https://server.example/image"/>

А сервер может ответить содержимым или ошибкой, в зависимости от того, доступен ли файл cookie:

app.get('/image', (req, res) => {
  const headers = req.headers;
  const cookieHeader = headers.cookie;
  // Check if the embed has the necessary cookie access
  if (!cookieHeader || !cookieHeader.includes('foo')) {
  // If the cookie is not present, check if the browser supports Storage Access headers
    if (
      'sec-fetch-storage-access' in headers &&
      headers['sec-fetch-storage-access'] == 'inactive'
    ) {
    // If the browser supports Storage Access API, retry the request with storage access enabled
      res.setHeader('Activate-Storage-Access', 'retry; allowed-origin="https://embedding-site.example"');
    }
    res.status(401).send('No cookie!');
   } else {
    // If the cookie is available, check if the user is authorized to access the image
    if (!check_authorization(cookieHeader)) {
      return res.status(401).send('Unauthorized!');
    }
    // If the user is authorized, respond with the image file
    res.sendFile("path/to/image.jpeg");
  }
});

Если cookie недоступен, сервер проверяет значение заголовка запроса Sec-Fetch-Storage-Access . Если это значение установлено как inactive , сервер отвечает заголовком Activate-Storage-Access: retry , указывающим, что запрос следует повторить с доступом к хранилищу. Если cookie отсутствует и заголовок Sec-Fetch-Storage-Access не имеет значения inactive, изображение не загрузится.

Поток HTTP-заголовков

С помощью HTTP-заголовков браузер может распознать, когда пользователь уже предоставил виджету разрешение на доступ к хранилищу, и загрузить iframe с доступом к неразделенным cookie-файлам во время последующих посещений.

При использовании заголовков доступа к хранилищу последующие посещения страниц будут инициировать следующий поток:

Пользователь снова посещает website.example , в который встроен calendar.example . Эта выборка пока не имеет доступа к cookie, как и раньше. Однако пользователь ранее предоставил разрешение storage-access , и выборка включает заголовок Sec-Fetch-Storage-Access: inactive , указывающий на то, что доступ к неразделенному cookie возможен, но не используется.
Сервер calendar.example отвечает заголовком Activate-Storage-Access: retry; allowed-origin="<origin>" (в этом случае <origin> будет https://website.example ), чтобы указать, что для извлечения ресурса требуется использование неразделенных файлов cookie с разрешением на доступ к хранилищу.
Браузер повторяет запрос, на этот раз включая неразделенные файлы cookie (активируя разрешение storage-access для этой выборки).
Сервер calendar.example отвечает персонализированным содержимым iframe. Ответ включает заголовок Activate-Storage-Access: load , указывающий, что браузер должен загрузить содержимое с активированным разрешением storage-access (другими словами, загрузить с неразделенным доступом к cookie, как если бы был вызван document.requestStorageAccess() ).
Пользовательский агент загружает содержимое iframe с неразделенным доступом к cookie, используя разрешение storage-access. После этого шага виджет может работать так, как и ожидалось.

Блок-схема, иллюстрирующая поток заголовка доступа к хранилищу. — Диаграмма потока заголовка доступа к хранилищу.

Обновите свое решение

Благодаря функции заголовков доступа к хранилищу вам может потребоваться обновить свой код в двух случаях:

Вы используете SAA и хотите добиться лучшей производительности с помощью логики заголовка.
У вас есть проверка или логика, которая зависит от того, включен ли заголовок Origin в запрос на вашем сервере.

Реализовать логику заголовков SAA

Чтобы использовать заголовки доступа к хранилищу в вашем решении, вам необходимо обновить свое решение. Предположим, вы являетесь владельцем calendar.example . Чтобы website.example мог загрузить персонализированный calendar.example , код виджета должен иметь доступ к хранилищу.

Клиентская сторона

Функция Storage Access Headers не требует обновления кода на стороне клиента для существующих решений. Прочтите документацию, чтобы узнать, как реализовать SAA .

Серверная часть

На стороне сервера вы можете использовать новые заголовки:

app.get('/cookie-access-endpoint', (req, res) => {
  const storageAccessHeader = req.headers['sec-fetch-storage-access'];

  if (storageAccessHeader === 'inactive') {
    // User needs to grant permission, trigger a prompt
    if (!validate_origin(req.headers.origin)) {
      res.status(401).send(`${req.headers.origin} is not allowed to send` +
          ' credentialed requests to this server.');
      return;
    }
    res.set('Activate-Storage-Access', `retry; allowed-origin="${req.headers.origin}"`);
    res.status(401).send('This resource requires storage access. Please grant permission.');
  } else if (storageAccessHeader === 'active') {
    // User has granted permission, proceed with access
    res.set('Activate-Storage-Access', 'load');
    // Include the actual iframe content here
    res.send('This is the content that requires cookie access.');
  } else {
    // Handle other cases (e.g., 'Sec-Fetch-Storage-Access': 'none')
  }
});

Посмотрите демо-версию, чтобы увидеть, как это решение работает на практике.

Обновите логику заголовка Origin

С помощью Storage Access Headers Chrome отправляет заголовок Origin в большем количестве запросов, чем раньше. Это может повлиять на вашу серверную логику, если она полагается на наличие заголовка Origin только для определенных типов запросов (например, определенных CORS).

Чтобы избежать потенциальных проблем, вам необходимо проверить код на стороне сервера:

Проверьте наличие любой проверки или логики, зависящей от наличия заголовка Origin .
Обновите свой код, чтобы обрабатывать заголовок Origin , присутствующий в большем количестве случаев.

Основные преимущества

Storage Access Headers — рекомендуемый, более производительный способ использования SAA. В целом, это изменение приносит несколько улучшений:

Поддержка встраивания без iframe: обеспечивает поддержку SAA для более широкого спектра ресурсов.
Сокращение использования сети: меньше запросов и меньший объем полезной нагрузки.
Меньше нагрузки на ЦП: меньше обработки JavaScript.
Улучшенный UX: устранение мешающих промежуточных загрузок.

Примите участие в исследовании происхождения

Пробные версии Origin позволяют вам попробовать новые функции и дать отзыв об их удобстве использования, практичности и эффективности. Для получения дополнительной информации ознакомьтесь с разделом Начало работы с пробными версиями Origin .

Вы можете попробовать функцию Storage Access Headers, зарегистрировавшись для участия в пробной версии Origin, начиная с Chrome 130. Чтобы принять участие в пробной версии Origin:

Перейдите на страницу регистрации пробной версии Storage Access Headers.
Следуйте инструкциям по участию в исследовании Origin.

Тест локально

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

Чтобы настроить экземпляр Chrome, выполните следующие действия:

Включите флаг Chrome на chrome://flags/#storage-access-headers .
Перезапустите Chrome, чтобы изменения вступили в силу.

Привлекайте и делитесь отзывами

Если у вас есть отзыв или вы столкнулись с какими-либо проблемами, вы можете подать заявку на получение информации . Вы также можете узнать больше о заголовках доступа к хранилищу на GitHub Explainer .