Teste de origem para suporte a cabeçalho HTTP no acesso ao Storage

Natalia Markoborodova

O Chrome está iniciando um teste de origem para adicionar cabeçalhos HTTP à API Storage Access (SAA) na versão 130: Cabeçalhos de acesso ao armazenamento. O novo cabeçalho de solicitação Sec-Fetch-Storage-Access e o cabeçalho de resposta Activate-Storage-Access têm como objetivo oferecer suporte a recursos que não são de iframe e melhorar o desempenho e a experiência do usuário em sites que dependem de conteúdo incorporado, como widgets de redes sociais, calendários e ferramentas interativas.

Fluxo do JavaScript (e limitações)

Antes, o SAA exigia uma chamada de API JavaScript para document.requestStorageAccess() em cada recarregamento, mesmo que o usuário já tivesse concedido permissão. Embora seja eficaz, esse método tem limitações:

• Várias viagens de ida e volta na rede:muitas vezes, o processo envolvia várias solicitações de rede e recarregamentos de página antes que o conteúdo incorporado pudesse funcionar totalmente.
• Dependência de iframe:a execução do JavaScript exigia o uso de iframes ou sub-recursos dentro de iframes, limitando a flexibilidade dos desenvolvedores.

Por exemplo, um widget de calendário do calendar.example incorporado em website.example usando apenas JavaScript teria esta aparência:

1. Carregar um marcador de posição:website.example solicita o widget. Como o widget calendar.example incorporado em website.example não tem acesso aos cookies não particionados, um widget de marcador de posição é renderizado.
2. Solicitar permissão:o marcador de posição é carregado e chama document.requestStorageAccess() para solicitar a permissão storage-access.
3. O usuário escolhe conceder permissão.
4. Recarregue o widget:o widget é atualizado, desta vez com acesso a cookies, e carrega o conteúdo personalizado.
5. Cada vez que o usuário visita um site que incorpora o widget calendar.example novamente, o fluxo é exatamente igual às etapas 1, 2 e 4. A única simplificação é que o usuário não precisa conceder acesso novamente.

Esse fluxo é ineficiente: se o usuário já tiver concedido permissão de armazenamento, o carregamento inicial do iframe, a chamada document.requestStorageAccess() e a recarga subsequente se tornam desnecessários e criam latência.

O novo fluxo com cabeçalhos HTTP

Os novos cabeçalhos de acesso ao armazenamento permitem um carregamento mais eficiente de conteúdo incorporado, incluindo recursos que não são iframes.

Com os cabeçalhos de acesso ao armazenamento, o navegador busca automaticamente recursos com o cabeçalho de solicitação Sec-Fetch-Storage-Access: inactive definido se o usuário já tiver concedido permissão. Nenhuma ação do desenvolvedor é necessária para definir o cabeçalho da solicitação. O servidor pode responder com o cabeçalho Activate-Storage-Access: retry; allowed-origin="<origin>", e o navegador vai tentar novamente a solicitação com as credenciais necessárias.

Cabeçalho de solicitação

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

Quando um usuário visita uma página que incorpora conteúdo entre sites, o navegador inclui automaticamente o cabeçalho Sec-Fetch-Storage-Access em solicitações entre sites que podem exigir credenciais (como cookies). Esse cabeçalho indica o status da permissão de acesso a cookies da incorporação. Veja como interpretar os valores:

• none: a incorporação não tem a permissão storage-access e, portanto, não tem acesso a cookies não particionados.
• inactive: a incorporação tem a permissão storage-access, mas não optou por usá-la. A incorporação não tem acesso a cookies não particionados.
• active: o embed tem acesso a cookies não particionados. Esse valor será incluído em todas as solicitações de origem cruzada que tiverem acesso a cookies não particionados.

Cabeçalhos de resposta

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

O cabeçalho Activate-Storage-Access instrui o navegador a tentar novamente a solicitação com cookies ou carregar o recurso diretamente com a SAA ativada. O cabeçalho pode ter os seguintes valores:

• load: instrui o navegador a conceder ao incorporador acesso a cookies não particionados para o recurso solicitado.
• retry: o servidor responde que o navegador precisa ativar a permissão de acesso ao armazenamento e tentar fazer a solicitação novamente.

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

Suporte para recursos que não são iframes

A atualização dos cabeçalhos de acesso ao armazenamento permite o SAA para conteúdo incorporado que não seja um iframe, como imagens hospedadas em um domínio diferente. Antes, nenhuma API da plataforma da Web permitia carregar esses recursos com credenciais em navegadores se os cookies de terceiros não estivessem disponíveis. Por exemplo, seu embedding-site.example pode pedir uma imagem:

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

O servidor pode responder com conteúdo ou um erro, dependendo da disponibilidade de um 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");
  }
});

Se o cookie não estiver disponível, o servidor vai verificar o valor do cabeçalho de solicitação Sec-Fetch-Storage-Access. Se esse valor for definido como inactive, o servidor vai responder com o cabeçalho Activate-Storage-Access: retry, indicando que a solicitação precisa ser repetida com acesso ao armazenamento. Se não houver cookie e o cabeçalho Sec-Fetch-Storage-Access não tiver o valor "inactive", a imagem não será carregada.

Fluxo de cabeçalho HTTP

Com os cabeçalhos HTTP, o navegador pode reconhecer quando o usuário já concedeu permissão de acesso ao armazenamento para o widget e carregar o iframe com acesso a cookies não particionados durante as visitas subsequentes.

Com os cabeçalhos de acesso ao armazenamento, as visitas às páginas subsequentes vão acionar o seguinte fluxo:

1. O usuário visita website.example, que tem o calendar.example incorporado novamente. Essa busca ainda não tem acesso ao cookie, como antes. No entanto, o usuário já concedeu a permissão storage-access, e a busca inclui um cabeçalho Sec-Fetch-Storage-Access: inactive para indicar que o acesso a cookies não particionados está disponível, mas não em uso.
2. O servidor calendar.example responde com um cabeçalho Activate-Storage-Access: retry; allowed-origin="<origin>" (neste caso, <origin> seria https://website.example) para indicar que a busca de recursos exige o uso de cookies não particionados com a permissão de acesso ao armazenamento.
3. O navegador tenta novamente a solicitação, desta vez incluindo cookies não particionados (ativando a permissão storage-access para essa busca).
4. O servidor calendar.example responde com o conteúdo personalizado do iframe. A resposta inclui um cabeçalho Activate-Storage-Access: load para indicar que o navegador precisa carregar o conteúdo com a permissão storage-access ativada. Em outras palavras, carregar com acesso a cookies não particionados, como se document.requestStorageAccess() tivesse sido chamado.
5. O user agent carrega o conteúdo do iframe com acesso a cookies não particionados usando a permissão storage-access. Depois dessa etapa, o widget poderá funcionar como esperado.

Atualizar sua solução

Com o recurso de cabeçalhos de acesso ao armazenamento, talvez seja necessário atualizar seu código em dois casos:

1. Você usa a SAA e quer melhorar a performance com a lógica de cabeçalho.
2. Você tem uma validação ou lógica que depende de o cabeçalho Origin estar incluído na solicitação no seu servidor.

Implementar a lógica de cabeçalhos da SAA

Para usar os cabeçalhos de acesso ao armazenamento na sua solução, atualize-a. Suponha que você seja o proprietário de calendar.example. Para que o website.example possa carregar um widget calendar.example personalizado, o código do widget precisa ter acesso ao armazenamento.

Lado do cliente

O recurso de cabeçalhos de acesso ao armazenamento não exige nenhuma atualização de código no lado do cliente para as soluções atuais. Leia a documentação para saber como implementar o SAA.

Lado do servidor

No lado do servidor, você pode usar os novos cabeçalhos:

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')
  }
});

Confira a demonstração para ver como essa solução funciona na prática.

Atualizar a lógica do cabeçalho de origem

Com os cabeçalhos de acesso ao armazenamento, o Chrome envia o cabeçalho Origin em mais solicitações do que antes. Isso pode afetar sua lógica do lado do servidor se ela depender da presença do cabeçalho "Origin" apenas para tipos específicos de solicitações (como as definidas pelo CORS).

Para evitar possíveis problemas, revise o código do lado do servidor:

• Verifique se há validação ou lógica que dependa da presença do cabeçalho Origin.
• Atualize seu código para processar o cabeçalho Origin em mais casos.

Veja as principais vantagens

Os cabeçalhos de acesso ao armazenamento são uma maneira recomendada e mais eficiente de usar a SAA. No geral, essa mudança traz várias melhorias:

• Compatibilidade com incorporações que não são iframes:permite o SAA para uma variedade maior de recursos.
• Uso reduzido da rede:menos solicitações e payloads menores.
• Menor uso da CPU:menos processamento de JavaScript.
• Melhoria na experiência do usuário:elimina cargas intermediárias disruptivas.

Participar do teste de origem

Com os testes de origem, você pode testar novos recursos e enviar feedback sobre a usabilidade, a praticidade e a eficácia deles. Para mais informações, consulte Começar a usar os testes de origem.

Para testar o recurso de cabeçalhos de acesso ao armazenamento, inscreva-se nos testes de origem a partir do Chrome 130. Para participar do teste de origem:

1. Acesse a página de registro do teste de origem dos cabeçalhos de acesso ao armazenamento.
2. Siga as instruções sobre a participação no teste de origem.

Testar localmente

Você pode testar o recurso de cabeçalhos de acesso ao armazenamento localmente para garantir que seu site esteja preparado para essa mudança.

Siga estas etapas para configurar sua instância do Chrome:

1. Ative a flag do Chrome no chrome://flags/#storage-access-headers.
2. Reinicie o Chrome para que as mudanças entrem em vigor.

Engajamento e como compartilhar feedback

Se você tiver feedback ou encontrar algum problema, registre uma questão. Você também pode saber mais sobre os cabeçalhos de acesso ao armazenamento na explicação do GitHub.