Prova dell'origine per il supporto dell'intestazione HTTP in Storage Access

Natalia Markoborodova

Chrome sta avviando una prova dell'origine per l'aggiunta di intestazioni HTTP all'API Storage Access (SAA) nella versione 130: Intestazioni di accesso allo spazio di archiviazione. Il nuovo Sec-Fetch-Storage-Access request header e Activate-Storage-Access response header hanno lo scopo di supportare le risorse non iframe e migliorare le prestazioni e l'esperienza utente per i siti web che si basano su contenuti incorporati, come widget di social media, calendari e strumenti interattivi.

Flusso di JavaScript (e relative limitazioni)

In precedenza, l'ASA richiedeva una chiamata all'API JavaScript a document.requestStorageAccess() a ogni ricarica, anche se l'utente aveva già concesso l'autorizzazione. Sebbene efficace, questo metodo presenta delle limitazioni:

• Più viaggi di andata e ritorno sulla rete: il processo spesso prevedeva diverse richieste di rete e ricaricamenti della pagina prima che i contenuti incorporati potessero funzionare completamente.
• Dipendenza da iframe:l'esecuzione di JavaScript richiedeva l'utilizzo di iframe o risorse secondarie all'interno di iframe, limitando la flessibilità per gli sviluppatori.

Ad esempio, un widget di calendario di calendar.example incorporato in website.example utilizzando solo JavaScript avrà il seguente aspetto:

1. Carica un segnaposto:website.example richiede il widget. Poiché il widget calendar.example incorporato in website.example non ha accesso ai cookie non partizionati, viene visualizzato un widget segnaposto.
2. Richiedi autorizzazione:il segnaposto viene caricato e poi chiama document.requestStorageAccess() per richiedere l'autorizzazione storage-access.
3. L'utente sceglie di concedere l'autorizzazione.
4. Ricarica il widget:il widget viene aggiornato, questa volta con accesso ai cookie, e infine carica i contenuti personalizzati.
5. Ogni volta che l'utente visita un sito che incorpora di nuovo il widget calendar.example, il flusso è esattamente lo stesso dei passaggi 1, 2 e 4; l'unica semplificazione è che l'utente non deve concedere di nuovo l'accesso.

Questo flusso non è efficiente: se l'utente ha già concesso l'autorizzazione di archiviazione, il caricamento iniziale dell'iframe, la chiamata document.requestStorageAccess() e il successivo ricaricamento diventano non necessari e creano latenza.

Il nuovo flusso con le intestazioni HTTP

I nuovi intestazioni di accesso allo spazio di archiviazione consentono un caricamento più efficiente dei contenuti incorporati, incluse le risorse non iframe.

Con le intestazioni di accesso allo spazio di archiviazione, il browser recupererà automaticamente le risorse con l'intestazione della richiesta Sec-Fetch-Storage-Access: inactive impostata se l'utente ha già concesso l'autorizzazione. Non è richiesta alcuna azione dello sviluppatore per impostare l'intestazione della richiesta. Il server può rispondere con l'intestazione Activate-Storage-Access: retry; allowed-origin="<origin>" e il browser riproverà a inviare la richiesta con le credenziali necessarie.

Importante: questo aggiornamento non modifica la procedura di richiesta iniziale delle autorizzazioni. I siti web devono comunque incorporare un iframe che chiami document.requestStorageAccess() per richiedere l'autorizzazione dell'utente se non è ancora stata concessa.

Intestazione della richiesta

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

Quando un utente visita una pagina che incorpora contenuti cross-site, il browser includerà automaticamente l'intestazione Sec-Fetch-Storage-Access nelle richieste cross-site che potrebbero richiedere credenziali (come i cookie). Questa intestazione indica lo stato dell'autorizzazione di accesso ai cookie dell'embed. Ecco come interpretare i relativi valori:

• none: l'embed non dispone dell'autorizzazione storage-access e, pertanto, non ha accesso ai cookie non partizionati.
• inactive: l'embed dispone dell'autorizzazione storage-access, ma non l'ha attivata. L'incorporamento non ha accesso ai cookie non partizionati.
• active: l'incorporamento ha accesso ai cookie non partizionato. Questo valore verrà incluso in tutte le richieste cross-origin che hanno accesso ai cookie non partizionati.

Intestazioni della risposta

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

L'intestazione Activate-Storage-Access indica al browser di riprovare a inviare la richiesta con i cookie o di caricare la risorsa direttamente con l'AA attivato. L'intestazione può avere i seguenti valori:

• load: indica al browser di concedere all'inserzionista l'accesso ai cookie non partizionati per la risorsa richiesta.
• retry: il server risponde che il browser deve attivare l'autorizzazione di accesso allo spazio di archiviazione, quindi riprova a inviare la richiesta.

Importante: quando utilizzi retry, la risposta deve includere anche il parametro allowed-origin per concedere a un'origine l'autorizzazione a inviare richieste con credenziali al tuo server. Inoltre, la richiesta iniziale deve aver incluso l'intestazione Sec-Fetch-Storage-Access: inactive.

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

Supporto per le risorse non iframe

L'aggiornamento degli intestazioni di accesso allo spazio di archiviazione abilita l'accesso allo spazio di archiviazione per i contenuti incorporati non iframe, come le immagini ospitate su un dominio diverso. In precedenza, nessuna API della piattaforma web consentiva di caricare queste risorse con le credenziali nei browser se i cookie di terze parti non erano disponibili. Ad esempio, il tuo embedding-site.example può richiedere un'immagine:

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

Il server può rispondere con contenuti o un errore, a seconda che sia disponibile un 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 il cookie non è disponibile, il server controlla il valore dell'intestazione della richiesta Sec-Fetch-Storage-Access. Se questo valore è impostato su inactive, il server risponde con l'intestazione Activate-Storage-Access: retry, indicando che la richiesta deve essere riprovata con l'accesso allo spazio di archiviazione. Se non è presente alcun cookie e l'intestazione Sec-Fetch-Storage-Access non ha il valore inattivo, l'immagine non verrà caricata.

Nota: puoi utilizzare l'intestazione Activate-Storage-Access: retry per le risorse non iframe senza utilizzare successivamente Activate-Storage-Access: load. L'intestazione di risposta load è destinata agli iframe ed è equivalente all'esecuzione di await document.requestStorageAccess() e al ricaricamento della finestra. Utilizzando il load header di risposta, l'iframe viene recuperato e caricato una sola volta.

Flusso delle intestazioni HTTP

Con le intestazioni HTTP, il browser può riconoscere quando l'utente ha già concesso l'autorizzazione di accesso allo spazio di archiviazione al widget e caricare l'iframe con accesso ai cookie non partizionati durante le visite successive.

Con le intestazioni di accesso allo spazio di archiviazione, le visite alle pagine successive attiveranno il seguente flusso:

1. L'utente visita di nuovo website.example, che contiene calendar.example incorporato. Questo recupero non ha ancora accesso al cookie, come in precedenza. Tuttavia, l'utente ha concesso in precedenza l'autorizzazione storage-access e il recupero include un'intestazione Sec-Fetch-Storage-Access: inactive per indicare che l'accesso ai cookie non partizionati è disponibile, ma non in uso.
2. Il server calendar.example risponde con un'intestazione Activate-Storage-Access: retry; allowed-origin="<origin>" (in questo caso, <origin> sarebbe https://website.example) per indicare che il recupero della risorsa richiede l'utilizzo di cookie non partizionati con l'autorizzazione di accesso allo spazio di archiviazione.
3. Il browser riprova a inviare la richiesta, questa volta includendo i cookie non partizionati (attivando l'autorizzazione storage-access per questo recupero).
4. Il server calendar.example risponde con i contenuti dell'iframe personalizzato. La risposta include un'intestazione Activate-Storage-Access: load per indicare che il browser deve caricare i contenuti con l'autorizzazione storage-access attivata (in altre parole, caricare con accesso ai cookie non partizionato, come se fosse stata chiamata document.requestStorageAccess()).
5. L'user agent carica i contenuti dell'iframe con accesso ai cookie non partizionato utilizzando l'autorizzazione di accesso allo spazio di archiviazione. Dopo questo passaggio, il widget può funzionare come previsto.

Diagramma di flusso dell'intestazione di accesso allo spazio di archiviazione.

Aggiornare la soluzione

Con la funzionalità Intestazioni di accesso allo spazio di archiviazione, ti consigliamo di aggiornare il codice in due casi:

1. Utilizzi SAA e vuoi ottenere un rendimento migliore con la logica dell'intestazione.
2. Hai una convalida o una logica che dipende dal fatto che l'intestazione Origin sia inclusa nella richiesta sul tuo server.

Implementa la logica delle intestazioni SAA

Per utilizzare gli intestazioni di accesso allo spazio di archiviazione nella tua soluzione, devi aggiornarla. Supponiamo che tu sia il proprietario di calendar.example. Affinché website.example possa caricare un widget website.example personalizzato, il codice del widget deve avere accesso allo spazio di archiviazione.calendar.example

Lato client

La funzionalità Intestazioni di accesso allo spazio di archiviazione non richiede alcun aggiornamento del codice lato client per le soluzioni esistenti. Leggi la documentazione per scoprire come implementare SAA.

Lato server

Sul lato server, puoi utilizzare le nuove intestazioni:

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

Dai un'occhiata alla demo per scoprire come funziona questa soluzione in pratica.

Aggiorna la logica dell'intestazione Origin

Con le intestazioni di accesso allo spazio di archiviazione, Chrome invia l'intestazione Origin in più richieste rispetto a prima. Ciò potrebbe influire sulla logica lato server se si basa sulla presenza dell'intestazione Origin solo per tipi specifici di richieste (come quelle definite da CORS).

Per evitare potenziali problemi, devi esaminare il codice lato server:

• Controlla la presenza di convalide o logiche che dipendono dalla presenza dell'intestazione Origin.
• Aggiorna il codice per gestire la presenza dell'intestazione Origin in più casi.

Vantaggi principali

Le intestazioni di accesso allo spazio di archiviazione sono un modo consigliato e più efficace per utilizzare l'autorizzazione di accesso allo spazio di archiviazione. Nel complesso, questa modifica apporta diversi miglioramenti:

• Supporto di incorporamenti non iframe:consente l'ASA per una gamma più ampia di risorse.
• Riduzione dell'utilizzo della rete: meno richieste e payload più piccoli.
• Utilizzo ridotto della CPU: meno elaborazione JavaScript.
• Miglioramento dell'esperienza utente:vengono eliminati i caricamenti intermedi che interrompono l'esperienza.

Partecipare alla prova dell'origine

Origin trials ti consente di provare nuove funzionalità e di fornire feedback sulla loro usabilità, praticità ed efficacia. Per ulteriori informazioni, consulta la guida introduttiva ai trial delle origini.

Puoi provare la funzionalità degli intestazioni di accesso allo spazio di archiviazione registrandoti alle prove dell'origine a partire da Chrome 130. Per partecipare alla prova dell'origine:

1. Vai alla pagina di registrazione della prova dell'origine degli intestazioni di accesso allo spazio di archiviazione.
2. Segui le istruzioni per la partecipazione alla prova di origine.

Eseguire il test localmente

Puoi testare la funzionalità Intestazioni di accesso allo spazio di archiviazione localmente per assicurarti che il tuo sito web sia pronto per questa modifica.

Per configurare l'istanza di Chrome:

1. Attiva il flag di Chrome su chrome://flags/#storage-access-headers.
2. Riavvia Chrome per applicare le modifiche.

Coinvolgere e condividere feedback

Se hai un feedback o riscontri un problema, puoi segnalare un problema. Puoi anche scoprire di più sugli intestazioni di accesso allo spazio di archiviazione nella guida di GitHub.