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 header della richiesta Sec-Fetch-Storage-Access e l'header della risposta Activate-Storage-Access mirano a supportare le risorse non iframe e a 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 JavaScript (e relativi limiti)

In precedenza, SAA richiedeva una chiamata API JavaScript a document.requestStorageAccess() a ogni ricaricamento, anche se l'utente aveva già concesso l'autorizzazione. Sebbene efficace, questo metodo introduce dei limiti:

• Più round trip di rete:il processo spesso prevedeva diverse richieste di rete e ricaricamenti di pagina prima che i contenuti incorporati potessero funzionare correttamente.
• Dipendenza dagli iframe:l'esecuzione di JavaScript imponeva l'utilizzo di iframe o risorse secondarie all'interno degli iframe, limitando la flessibilità per gli sviluppatori.

Ad esempio, un widget calendario di calendar.example incorporato in website.example utilizzando solo JavaScript avrebbe 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 propri cookie non partizionati, viene visualizzato un widget segnaposto.
2. Richiedi autorizzazione:il segnaposto viene caricato, quindi 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 l'accesso ai cookie, e infine carica i contenuti personalizzati.
5. Ogni volta che l'utente visita di nuovo un sito che incorpora il widget calendar.example, il flusso è esattamente lo stesso dei passaggi 1, 2 e 4; l'unica semplificazione è che l'utente non deve concedere nuovamente l'accesso.

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

Il nuovo flusso con le intestazioni HTTP

Le nuove intestazioni Storage Access consentono un caricamento più efficiente dei contenuti incorporati, incluse le risorse non iframe.

Con le intestazioni Storage Access, 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 ritenterà la richiesta con le credenziali necessarie.

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'incorporamento. Ecco come interpretare i suoi valori:

• none: l'incorporamento non dispone dell'autorizzazione storage-access e pertanto non ha accesso ai cookie non partizionati.
• inactive: l'incorporamento dispone dell'autorizzazione storage-access, ma non ha attivato il suo utilizzo. L'incorporamento non ha accesso ai cookie non partizionati.
• active: l'incorporamento ha accesso ai cookie non partizionati. Questo valore verrà incluso in tutte le richieste multiorigine 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'API Storage Access attivata. L'intestazione può avere i seguenti valori:

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

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 delle intestazioni di accesso allo spazio di archiviazione attiva SAA per i contenuti incorporati non iframe, come le immagini ospitate su un dominio diverso. In precedenza, nessuna API della piattaforma web consentiva il caricamento di 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 ritentata con l'accesso allo spazio di archiviazione. Se non è presente alcun cookie e l'intestazione Sec-Fetch-Storage-Access non ha il valore inactive, l'immagine non verrà caricata.

Flusso dell'intestazione 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 Storage Access, le visite alle pagine successive attiveranno il seguente flusso:

1. L'utente visita website.example che ha nuovamente incorporato calendar.example. Questo recupero non ha ancora accesso al cookie, come prima. Tuttavia, l'utente ha precedentemente concesso 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 personalizzati. La risposta include un'intestazione Activate-Storage-Access: load, per indicare che il browser deve caricare i contenuti con l'autorizzazione storage-access attivata (ovvero caricare con accesso ai cookie non partizionati, come se fosse stato chiamato document.requestStorageAccess()).
5. Lo user agent carica i contenuti dell'iframe con accesso ai cookie non partizionati utilizzando l'autorizzazione storage-access. Dopo questo passaggio, il widget può funzionare come previsto.

.

Aggiorna la soluzione

Con la funzionalità Storage Access Headers, potresti voler aggiornare il codice in due casi:

1. Utilizzi gli annunci di ricerca adattabili e vuoi ottenere un rendimento migliore con la logica delle intestazioni.
2. Sul tuo server è presente una convalida o una logica che dipende dall'inclusione o meno dell'intestazione Origin nella richiesta.

Implementare la logica delle intestazioni SAA

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

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

Guarda la demo per vedere come funziona questa soluzione in pratica.

Aggiornare la logica dell'intestazione Origin

Con le intestazioni Storage Access, 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 eventuali convalide o logiche che dipendono dalla presenza dell'intestazione Origin.
• Aggiorna il codice per gestire la presenza dell'intestazione Origin in più casi.

Principali vantaggi

Le intestazioni di accesso all'archiviazione sono un modo consigliato e più efficiente per utilizzare l'SAA. Nel complesso, questa modifica comporta diversi miglioramenti:

• Supporto degli incorporamenti non iframe: consente l'utilizzo di SAA per una gamma più ampia di risorse.
• Utilizzo ridotto della rete: meno richieste e payload più piccoli.
• Utilizzo ridotto della CPU:meno elaborazione JavaScript.
• Migliore UX:elimina i caricamenti intermedi che interrompono l'esperienza.

Partecipare alla prova dell'origine

Origin trials ti consente di provare nuove funzionalità e fornire feedback sulla loro usabilità, praticità ed efficacia. Per saperne di più, consulta la pagina Guida introduttiva alle prove di origine.

Puoi provare la funzionalità Storage Access Headers 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 delle intestazioni di accesso allo spazio di archiviazione.
2. Segui le istruzioni sulla partecipazione alla prova dell'origine.

Testare localmente

Puoi testare localmente la funzionalità delle intestazioni di accesso allo spazio di archiviazione 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.

Partecipare e condividere feedback

Se hai feedback o riscontri problemi, puoi segnalare un problema. Puoi anche scoprire di più sugli Storage Access Headers nella spiegazione di GitHub.