Accesso asincrono ai cookie HTTP

Victor Costan
X GitHub

Che cos'è l'API Cookie Store?

L'API Cookie Store espone i cookie HTTP ai service worker e offre un'alternativa asincrona a document.cookie. L'API fa sì che è più facile:

  • Evita i jank sul thread principale, accedendo ai cookie in modo asincrono.
  • Evita di eseguire il polling per i cookie, perché potrebbero essere osservate modifiche ai cookie.
  • Accedere ai cookie dei service worker.

Leggi la spiegazione

Stato attuale

Passaggio Stato
1. Crea messaggio esplicativo Completato
2. Crea la bozza iniziale delle specifiche Completato
**3. Raccogli feedback e esegui l'iterazione delle specifiche** **In corso**
4. Prova dell'origine In pausa
5. Avvia Non avviato

Come si utilizza l'archivio cookie asincrono?

Attiva la prova dell'origine

Per provarla localmente, l'API può essere abilitata dalla riga di comando:

chrome --enable-blink-features=CookieStore

Il passaggio di questo flag nella riga di comando abilita l'API a livello globale in Chrome per la sessione corrente.

In alternativa, puoi attivare #enable-experimental-web-platform-features in chrome://flags.

Probabilmente non hai bisogno dei cookie

Prima di addentrarci nella nuova API, vorrei sottolineare che i cookie sono ancora la peggiore primitiva di archiviazione lato client della piattaforma e deve essere comunque usata ultima risorsa. Non è un caso: i cookie sono stati il primo lato client del Web meccanismo di archiviazione e abbiamo imparato molto da allora.

I motivi principali per evitare i cookie sono:

  • I cookie importano lo schema di archiviazione nell'API back-end. Ogni richiesta HTTP trasporta uno snapshot dell'archivio cookie. In questo modo è più facile tecnici del back-end per introdurre dipendenze nell'attuale formato dei cookie. Una volta Ciò accade, il front-end non può modificare il proprio schema di archiviazione senza eseguire il deployment una modifica corrispondente al backend.

  • I cookie hanno un modello di sicurezza complesso. Le funzionalità delle piattaforme web moderne seguono la stessa politica di origine, il che significa che ciascuna applicazione ha la propria sandbox ed è completamente indipendente altre applicazioni che l'utente potrebbe eseguire. Ambiti dei cookie costituisce una storia di sicurezza significativamente più complessa e il semplice tentativo riassumere che raddoppierebbe la dimensione di questo articolo.

  • I cookie hanno costi per le prestazioni elevate. I browser devono includere un'istantanea cookie in ogni richiesta HTTP, quindi ogni modifica ai cookie deve vengono propagate negli stack di rete e di archiviazione. I browser moderni hanno un'elevata implementazioni ottimizzate dei cookie, ma non riusciremo mai i cookie sono efficienti quanto gli altri meccanismi di archiviazione, che non hanno bisogno di parlare allo stack di rete.

Per tutti i motivi descritti sopra, le applicazioni web moderne dovrebbero evitare i cookie e un identificatore di sessione IndexedDB e aggiungere esplicitamente l'identificatore all'intestazione o al corpo di richieste HTTP specifiche; tramite l'API fetch.

Detto questo, stai ancora leggendo questo articolo perché hai una buona motivo per utilizzare i cookie...

Il venerabile document.cookie L'API è una fonte di jank abbastanza garantita per la tua applicazione. Ad esempio: ogni volta che utilizzi il getter document.cookie, il browser deve interrompere l'esecuzione JavaScript finché non dispone delle informazioni sui cookie da te richieste. L'operazione può richiedere hop di processo o la lettura di un disco e causerà il jank della tua UI.

Una soluzione semplice per questo problema è passare da document.cookie getter all'API asincrona Cookie Store.

await cookieStore.get('session_id');

// {
//   domain: "example.com",
//   expires: 1593745721000,
//   name: "session_id",
//   path: "/",
//   sameSite: "unrestricted",
//   secure: true,
//   value: "yxlgco2xtqb.ly25tv3tkb8"
// }

Il setter document.cookie può essere sostituito in modo simile. Aspetti da tenere presenti che la modifica deve essere applicata solo dopo la promessa restituita da Risoluzione di cookieStore.set.

await cookieStore.set({name: 'opt_out', value: '1'});

// undefined

Osserva, non fare un sondaggio

Un'applicazione molto diffusa per l'accesso ai cookie da JavaScript rileva quando l'utente si disconnette e l'aggiornamento della UI. Al momento si fa tramite sondaggi document.cookie, che introduce jank e ha un impatto negativo sulla batteria vita privata.

L'API Cookie Store offre un metodo alternativo per l'osservazione dei cookie modifiche, che non richiedono il polling.

cookieStore.addEventListener('change', event => {
  for (const cookie of event.changed) {
    if (cookie.name === 'session_id') sessionCookieChanged(cookie.value);
  }
  for (const cookie of event.deleted) {
    if (cookie.name === 'session_id') sessionCookieChanged(null);
  }
});

Dai il benvenuto ai Service worker

A causa della progettazione sincrona, l'API document.cookie non è stata apportata disponibili per Service worker. L'API Cookie Store è asincrona e pertanto è consentita nel servizio worker.

L'interazione con i cookie funziona allo stesso modo nei contesti dei documenti e Service worker.

// Works in documents and service workers.
async function logOut() {
  await cookieStore.delete('session_id');
}

Tuttavia, l'osservazione delle modifiche ai cookie è un po' diversa nei Service worker. Risveglio un service worker può essere piuttosto costoso, quindi dobbiamo descrivere esplicitamente il cookie cambia a cui il worker è interessato.

Nell'esempio riportato di seguito, un'applicazione che utilizza IndexedDB per memorizzare nella cache i dati utente monitora le modifiche al cookie di sessione ed elimina i dati memorizzati nella cache quando l'utente si disconnette.

// Specify the cookie changes we're interested in during the install event.
self.addEventListener('install', event => {
  event.waitUntil(cookieStore.subscribeToChanges([{name: 'session_id'}]));
});

// Delete cached data when the user logs out.
self.addEventListener('cookiechange', event => {
  for (const cookie of event.deleted) {
    if (cookie.name === 'session_id') {
      indexedDB.deleteDatabase('user_cache');
      break;
    }
  }
});

Best practice

Disponibile a breve.

Feedback

Se provi questa API, facci sapere cosa ne pensi. Invia indicazioni feedback sulla forma dell'API repository di specifiche, e segnalare eventuali bug di implementazione al Blink>Storage>CookiesAPI Componente Blink.

Ci interessa soprattutto conoscere le misurazioni delle prestazioni e l'uso casi diversi da quelli descritti nel spiegatore.

Risorse aggiuntive