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 acceso al almacenamiento. El nuevo encabezado de solicitud Sec-Fetch-Storage-Access y el encabezado de respuesta Activate-Storage-Access tienen como objetivo admitir recursos que no sean de iframe y mejorar el rendimiento y la experiencia del usuario de los sitios web que dependen de contenido incorporado, como widgets de redes sociales, calendarios y herramientas interactivas.

Flujo de JavaScript (y sus limitaciones)

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

• Varios viajes de ida y vuelta de red: A menudo, el proceso implicaba varias solicitudes de red y cargas 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 de los desarrolladores.

Por ejemplo, un widget de calendario de calendar.example incorporado en website.example que solo use 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. Solicita permiso: Se carga el marcador de posición y, luego, se llama a document.requestStorageAccess() para solicitar el permiso storage-access.
3. El usuario elige otorgar el permiso.
4. Volver a cargar el widget: El widget se actualiza, esta vez con acceso a las cookies, y, por último, carga el contenido personalizado.
5. Cada vez que el usuario visita un sitio que vuelve a incorporar el widget 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ó el permiso de almacenamiento, la carga inicial del iframe, la llamada a document.requestStorageAccess() y la recarga posterior se vuelven innecesarias y crean latencia.

El nuevo flujo con encabezados HTTP

Los nuevos encabezados de acceso al almacenamiento permiten una carga más eficiente del contenido incorporado, incluidos los recursos que no son de iframe.

Con los encabezados de acceso al almacenamiento, el navegador recuperará automáticamente los recursos con el encabezado de solicitud Sec-Fetch-Storage-Access: inactive establecido si el usuario ya otorgó permiso. No es necesario que el desarrollador realice ninguna acción 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.

Importante: Esta actualización no cambia el proceso inicial de solicitud de permisos. Los sitios web aún deben incorporar un iframe que llame a document.requestStorageAccess() para solicitar el permiso del usuario si aún no se otorgó.

Encabezado de la solicitud

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

Cuando un usuario visita una página que incorpora contenido entre sitios, el navegador incluye automáticamente el encabezado Sec-Fetch-Storage-Access en las solicitudes entre sitios que podrían requerir credenciales (como cookies). Este encabezado indica el estado del permiso de acceso a cookies de la incorporación. A continuación, te mostramos cómo interpretar sus valores:

• none: La incorporación no tiene el permiso storage-access y, por lo tanto, no tiene acceso a las cookies no particionadas.
• inactive: La incorporación tiene el permiso storage-access, pero no se habilitó para usarlo. La incorporación no tiene acceso a cookies no particionadas.
• active: La incorporación tiene acceso a cookies no particionadas. Este valor se incluirá en todas las solicitudes entre orígenes que tengan acceso a cookies no particionadas.

Encabezados de respuesta

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

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

• load: Indica al navegador que otorgue al incorporador 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.

Importante: Cuando uses retry, tu respuesta también debe incluir el parámetro allowed-origin para otorgarle un permiso de origen para enviar solicitudes con credenciales a tu servidor. Además, la solicitud inicial debe haber incluido el encabezado Sec-Fetch-Storage-Access: inactive.

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 acceso al almacenamiento 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 plataforma web permitía cargar esos recursos con credenciales en navegadores si las cookies de terceros no estaban disponibles. Por ejemplo, tu embedding-site.example puede solicitar una imagen de las siguientes maneras:

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

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 de almacenamiento. Si no hay una cookie y el encabezado Sec-Fetch-Storage-Access no tiene el valor inactivo, no se cargará la imagen.

Nota: Puedes usar el encabezado Activate-Storage-Access: retry para recursos que no sean de iframe sin usar Activate-Storage-Access: load posteriormente. El encabezado de respuesta load está diseñado para iframes y equivale a ejecutar await document.requestStorageAccess() y volver a cargar la ventana. Con el encabezado de respuesta load, el iframe solo se recupera y carga una vez.

Flujo de encabezados 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 acceso a almacenamiento, las visitas a páginas posteriores activarán el siguiente flujo:

1. El usuario vuelve a visitar website.example, que tiene el calendar.example incorporado. Esta recuperación aún no tiene acceso a la cookie, como antes. Sin embargo, el usuario otorgó previamente el permiso storage-access, y la recuperación incluye un encabezado Sec-Fetch-Storage-Access: inactive para indicar que el acceso a cookies no particionadas está disponible, pero no se está usando.
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 no particionadas con el permiso de acceso al almacenamiento.
3. El navegador vuelve a intentar la solicitud, esta vez, con las cookies no particionadas (activando el permiso storage-access para esta recuperación).
4. El servidor calendar.example responde con el contenido del iframe personalizado. 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 no particionadas, como si se hubiera llamado a document.requestStorageAccess()).
5. El usuario-agente carga el contenido del iframe con acceso a cookies no particionadas con el permiso de acceso al almacenamiento. Después de este paso, el widget puede funcionar como se espera.

Diagrama de flujo del encabezado de acceso al almacenamiento.

Actualiza tu solución

Con la función Encabezados de acceso al almacenamiento, te recomendamos que actualices tu código en dos casos:

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

Implementa la lógica de encabezados de SAA

Para usar los encabezados de acceso a almacenamiento 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 Encabezados de acceso al almacenamiento no requiere ninguna actualización de código del cliente para las soluciones existentes. Lee la documentación para obtener información sobre cómo implementar la SAA.

En el servidor

En el servidor, puedes usar los encabezados nuevos:

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 demo para ver cómo funciona esta solución en la práctica.

Actualiza la lógica del encabezado de origen

Con los encabezados de acceso al almacenamiento, Chrome envía el encabezado Origin en más solicitudes que antes. Esto podría afectar tu lógica del servidor si depende de que el encabezado Origin solo esté presente para tipos específicos de solicitudes (como los que define CORS).

Para evitar posibles problemas, debes revisar el 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 que el encabezado Origin esté presente en más casos.

Ventajas clave

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

• Compatibilidad con incorporaciones que no son de iframe: Habilita la SAA para un rango más amplio de recursos.
• Reducción del uso de red: Menos solicitudes y cargas útiles más pequeñas.
• Menor uso de la CPU: Menos procesamiento de JavaScript.
• UX mejorada: Elimina las cargas intermedias disruptivas.

Participa en la prueba de origen

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

Para probar la función de encabezados de acceso a almacenamiento, regístrate en las pruebas de origen a partir de la versión 130 de Chrome. Para participar en la prueba de origen, haz lo siguiente:

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

Realiza pruebas locales

Puedes probar la función encabezados de acceso al almacenamiento 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 acceso a almacenamiento en la explicación de GitHub.