Accesso asincrono ai cookie HTTP

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

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...

Lettura di un cookie ed eliminazione dei jank

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

• Spiegazione pubblica
• Specifiche
• Monitoraggio del bug
• voce chromestatus.com
• Thread del discorso WICG
• Componente lampeggiante: Blink>Storage>CookiesAPI