Prueba de origen para la compatibilidad con encabezados HTTP en el acceso a Storage

Natalia Markoborodova

Chrome comenzará una prueba de origen para agregar encabezados HTTP a la API de Storage Access (SAA) en la versión 130: Encabezados de Storage Access. Los nuevos encabezados de solicitud Sec-Fetch-Storage-Access y de respuesta Activate-Storage-Access tienen como objetivo admitir recursos que no son de iframe y mejorar el rendimiento y la experiencia del usuario en los sitios web que dependen de contenido incorporado, como widgets de redes sociales, calendarios y herramientas interactivas.

Flujo de JavaScript (y sus limitaciones)

Anteriormente, SAA requería una llamada a la API de JavaScript para document.requestStorageAccess() en cada recarga, incluso si el usuario ya había otorgado el permiso. Si bien es eficaz, este método presenta limitaciones:

• Múltiples viajes de ida y vuelta a la red: El proceso a menudo implicaba varias solicitudes de red y recargas de página antes de que el contenido incorporado pudiera funcionar por completo.
• Dependencia de iframe: La ejecución de JavaScript exigía el uso de iframes o subrecursos dentro de iframes, lo que limitaba la flexibilidad para los desarrolladores.

Por ejemplo, un widget de calendario de calendar.example incorporado en website.example solo con JavaScript se vería de la siguiente manera:

1. Carga un marcador de posición: website.example solicita el widget. Como el widget calendar.example incorporado en website.example no tiene acceso a sus cookies no particionadas, se renderiza un widget de marcador de posición.
2. Solicitar permiso: Se carga el marcador de posición y, luego, se llama a document.requestStorageAccess() para solicitar el permiso de storage-access.
3. El usuario elige otorgar permiso.
4. Vuelve a cargar el widget: El widget se actualiza, esta vez con acceso a las cookies, y, finalmente, carga el contenido personalizado.
5. Cada vez que el usuario vuelve a visitar un sitio que incorpora el widget de calendar.example, el flujo se ve exactamente igual que en los pasos 1, 2 y 4. La única simplificación es que el usuario no necesita volver a otorgar acceso.

Este flujo es ineficiente: si el usuario ya otorgó permiso de almacenamiento, la carga inicial del iframe, la llamada a document.requestStorageAccess() y la recarga posterior se vuelven innecesarias y generan latencia.

El nuevo flujo con encabezados HTTP

Los nuevos encabezados de Storage Access permiten una carga más eficiente del contenido integrado, incluidos los recursos que no son de iframe.

Con los encabezados de Storage Access, el navegador recuperará automáticamente los recursos con el encabezado de solicitud Sec-Fetch-Storage-Access: inactive establecido si el usuario ya otorgó el permiso. No se requiere ninguna acción por parte del desarrollador para establecer el encabezado de la solicitud. El servidor puede responder con el encabezado Activate-Storage-Access: retry; allowed-origin="<origin>", y el navegador volverá a intentar la solicitud con las credenciales necesarias.

Encabezado de la solicitud

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

Cuando un usuario visita una página que incorpora contenido de sitios cruzados, el navegador incluirá automáticamente el encabezado Sec-Fetch-Storage-Access en las solicitudes de sitios cruzados que puedan requerir credenciales (como cookies). Este encabezado indica el estado del permiso de acceso a las cookies del elemento integrado. A continuación, te explicamos cómo interpretar sus valores:

• none: El elemento integrado no tiene el permiso storage-access y, por lo tanto, no tiene acceso a las cookies sin particionar.
• inactive: La incorporación tiene el permiso storage-access, pero no habilitó su uso. La incorporación no tiene acceso a cookies sin particionar.
• active: La incorporación tiene acceso a cookies sin particionar. Este valor se incluirá en cualquier solicitud de origen cruzado que tenga acceso a cookies sin particionar.

Encabezados de respuesta

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

El encabezado Activate-Storage-Access indica al navegador que vuelva a intentar la solicitud con cookies o que cargue el recurso directamente con SAA activado. El encabezado puede tener los siguientes valores:

• load: Indica al navegador que otorgue al sitio incorporado acceso a las cookies no particionadas para el recurso solicitado.
• retry: El servidor responde que el navegador debe activar el permiso de acceso al almacenamiento y, luego, volver a intentar la solicitud.

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

Compatibilidad con recursos que no son de iframe

La actualización de los encabezados de Storage Access habilita la SAA para el contenido incorporado que no es de iframe, como las imágenes alojadas en un dominio diferente. Anteriormente, ninguna API de la plataforma web permitía cargar esos recursos con credenciales en los navegadores si las cookies de terceros no estaban disponibles. Por ejemplo, tu embedding-site.example puede solicitar una imagen:

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

Además, el servidor puede responder con contenido o un error, según si hay una cookie disponible:

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

Si la cookie no está disponible, el servidor verifica el valor del encabezado de solicitud Sec-Fetch-Storage-Access. Si este valor se establece en inactive, el servidor responde con el encabezado Activate-Storage-Access: retry, lo que indica que se debe volver a intentar la solicitud con acceso al almacenamiento. Si no hay una cookie y el encabezado Sec-Fetch-Storage-Access no tiene el valor inactivo, no se cargará la imagen.

Flujo de encabezado HTTP

Con los encabezados HTTP, el navegador puede reconocer cuando el usuario ya otorgó permiso de acceso al almacenamiento al widget y cargar el iframe con acceso a cookies no particionadas durante las visitas posteriores.

Con los encabezados de Storage Access, las visitas posteriores a las páginas activarán el siguiente flujo:

1. El usuario visita website.example, que vuelve a tener el elemento calendar.example incorporado. Esta recuperación aún no tiene acceso a la cookie, como antes. Sin embargo, el usuario ya otorgó el permiso storage-access y la recuperación incluye un encabezado Sec-Fetch-Storage-Access: inactive para indicar que el acceso a las cookies sin particionar está disponible, pero no en uso.
2. El servidor calendar.example responde con un encabezado Activate-Storage-Access: retry; allowed-origin="<origin>" (en este caso, <origin> sería https://website.example) para indicar que la recuperación de recursos requiere el uso de cookies sin particionar con el permiso de acceso al almacenamiento.
3. El navegador vuelve a intentar realizar la solicitud, esta vez incluyendo cookies sin particionar (lo que activa el permiso storage-access para esta recuperación).
4. El servidor calendar.example responde con el contenido personalizado del iframe. La respuesta incluye un encabezado Activate-Storage-Access: load para indicar que el navegador debe cargar el contenido con el permiso storage-access activado (en otras palabras, cargar con acceso a cookies sin particionar, como si se hubiera llamado a document.requestStorageAccess()).
5. El usuario-agente carga el contenido del iframe con acceso a cookies sin particionar a través del permiso de storage-access. Después de este paso, el widget puede funcionar según lo esperado.

Actualiza tu solución

Con la función Storage Access Headers, es posible que desees actualizar tu código en dos casos:

1. Utilizas los SAA y deseas lograr un mejor rendimiento con la lógica de encabezado.
2. Tienes una validación o lógica que depende de si el encabezado Origin se incluye en la solicitud en tu servidor.

Implementa la lógica de los encabezados de SAA

Para usar los encabezados de Storage Access en tu solución, debes actualizarla. Supongamos que eres el propietario de calendar.example. Para que website.example pueda cargar un widget calendar.example personalizado, el código del widget debe tener acceso al almacenamiento.

Del cliente

La función Storage Access Headers no requiere ninguna actualización de código del cliente para las soluciones existentes. Lee la documentación para saber cómo implementar la SAA.

En el servidor

En el servidor, puedes usar los nuevos encabezados:

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

Consulta la demostración para ver cómo funciona esta solución en la práctica.

Actualiza la lógica del encabezado Origin

Con los encabezados de Storage Access, Chrome envía el encabezado Origin en más solicitudes que antes. Esto podría afectar la lógica del servidor si se basa en que el encabezado Origin solo está presente para tipos específicos de solicitudes (como las definidas por CORS).

Para evitar posibles problemas, debes revisar tu código del servidor:

• Verifica si hay alguna validación o lógica que dependa de la presencia del encabezado Origin.
• Actualiza tu código para controlar el encabezado Origin en más casos.

Ventajas principales

Los encabezados de acceso al almacenamiento son una forma recomendada y más eficaz de usar la SAA. En general, este cambio trae varias mejoras:

• Compatibilidad con la incorporación de elementos que no son de iframe: Permite que SAA funcione con una mayor variedad de recursos.
• Menor uso de la red: Menos solicitudes y cargas útiles más pequeñas
• Menor uso de la CPU: Se procesa menos código JavaScript.
• UX mejorada: Elimina las cargas intermedias disruptivas.

Participa en la prueba de origen

Las pruebas de origen te permiten probar funciones nuevas y brindar comentarios sobre su usabilidad, practicidad y eficacia. Para obtener más información, consulta Cómo comenzar a usar las pruebas de origen.

Puedes probar la función Storage Access Headers registrándote en las pruebas de origen a partir de Chrome 130. Para participar en la prueba de origen, haz lo siguiente:

1. Ve a la página de registro de la prueba de origen de los encabezados de Storage Access.
2. Sigue las instrucciones para participar en la prueba de origen.

Realiza pruebas locales

Puedes probar la función Storage Access Headers de forma local para asegurarte de que tu sitio web esté preparado para este cambio.

Sigue estos pasos para configurar tu instancia de Chrome:

1. Habilita la marca de Chrome en chrome://flags/#storage-access-headers.
2. Reinicia Chrome para que se apliquen los cambios.

Interactúa y comparte comentarios

Si tienes comentarios o problemas, puedes informar un problema. También puedes obtener más información sobre los encabezados de Storage Access en la explicación de GitHub.