Il protocollo Web Push

Matt Gaunt

Abbiamo visto come è possibile usare una libreria per attivare i messaggi push, ma cosa fanno esattamente queste librerie?

Stanno facendo richieste di rete, garantendo al contempo il formato corretto. La specifica che definisce questa richiesta di rete è il protocollo Web Push.

Questa sezione descrive in che modo il server può identificarsi con le chiavi dei server delle applicazioni e come vengono inviati il payload criptato e i dati associati.

Non è un aspetto interessante del web push e io non sono esperto di crittografia, ma diamo un'occhiata a ogni articolo perché è utile sapere cosa fanno queste librerie in background.

Chiavi server delle applicazioni

Quando ci abboniamo a un utente, passiamo un applicationServerKey. Questa chiave viene passata al servizio push e utilizzata per verificare che l'applicazione che ha sottoscritto l'abbonamento all'utente sia anche l'applicazione che attiva i messaggi push.

Quando attiviamo un messaggio push, inviamo un insieme di intestazioni che consentono al servizio push di autenticare l'applicazione. (Questo valore è definito dalla specifica VAPID.)

Cosa significa esattamente tutto questo e cosa succede esattamente? Bene, questi sono i passaggi per l'autenticazione dei server applicazioni:

1. Il server delle applicazioni firma alcune informazioni JSON con la propria chiave applicazione privata.
2. Queste informazioni firmate vengono inviate al servizio push come intestazione in una richiesta POST.
3. Il servizio push utilizza la chiave pubblica memorizzata che ha ricevuto da pushManager.subscribe() per verificare che le informazioni ricevute siano firmate dalla chiave privata relativa alla chiave pubblica. Ricorda: la chiave pubblica è il valore applicationServerKey trasmesso nella chiamata di abbonamento.
4. Se le informazioni firmate sono valide, il servizio push invia il messaggio push all'utente.

Di seguito è riportato un esempio di questo flusso di informazioni. (Nota la legenda in basso a sinistra per indicare le chiavi pubbliche e private.)

Le "informazioni firmate" aggiunte a un'intestazione della richiesta sono un token web JSON.

Token web JSON

Un token web JSON (o JWT in breve) è un modo per inviare un messaggio a una terza parte in modo che il destinatario possa convalidare chi l'ha inviato.

Quando una terza parte riceve un messaggio, deve ottenere la chiave pubblica del mittente e utilizzarla per convalidare la firma del JWT. Se la firma è valida, il JWT deve essere stato firmato con la chiave privata corrispondente, quindi deve provenire dal mittente previsto.

Su https://jwt.io/ sono disponibili numerose librerie che possono eseguire la firma per te. Ti consiglio di farlo dove puoi. Per completezza, vediamo come creare manualmente un JWT firmato.

Push web e JWT firmati

Un JWT firmato è solo una stringa, anche se può essere pensato come tre stringhe unite da punti.

La prima e la seconda stringa (le informazioni JWT e i dati JWT) sono porzioni di JSON codificate in base64, che sono leggibili pubblicamente.

La prima stringa contiene informazioni sul JWT stesso, che indicano quale algoritmo è stato utilizzato per creare la firma.

Le informazioni JWT per il web push devono contenere le seguenti informazioni:

{
  "typ": "JWT",
  "alg": "ES256"
}

La seconda stringa contiene i dati JWT. che fornisce informazioni sul mittente del JWT, a chi è destinato e per quanto tempo è valido.

Per il web push, i dati avranno il seguente formato:

{
  "aud": "https://some-push-service.org",
  "exp": "1469618703",
  "sub": "mailto:[e-mail]"
}

Il valore aud è il "pubblico", ovvero il destinatario del JWT. Per il push web, il segmento di pubblico è il servizio push, quindi lo impostiamo sull'origine del servizio push.

Il valore exp è la scadenza del JWT, il che impedisce agli snooper di riutilizzare un JWT se lo intercettano. La scadenza è un timestamp in secondi e non deve essere più lungo di 24 ore.

In Node.js la scadenza viene impostata utilizzando:

Math.floor(Date.now() / 1000) + 12 * 60 * 60;

Sono necessarie 12 ore anziché 24 per evitare problemi con differenze di orologio tra l'applicazione di invio e il servizio push.

Infine, il valore sub deve essere un URL o un indirizzo email mailto. In questo modo, se un servizio push ha bisogno di contattare il mittente, possa trovare le informazioni di contatto del JWT. (Questo è il motivo per cui la libreria web-push aveva bisogno di un indirizzo email).

Proprio come per le informazioni JWT, i dati JWT sono codificati come stringa Base64 sicura per URL.

La terza stringa, la firma, è il risultato dell'unione delle prime due stringhe (le informazioni JWT e dei dati JWT) con un punto, che chiameremo "token non firmato", e la firma.

Il processo di firma richiede la crittografia del "token non firmato" tramite ES256. Secondo le specifiche JWT, ES256 sta per "ECDSA using the P-256 curve and the SHA-256 hash algoritmi". Utilizzando le criptovalute web, puoi creare la firma in questo modo:

// Utility function for UTF-8 encoding a string to an ArrayBuffer.
const utf8Encoder = new TextEncoder('utf-8');

// The unsigned token is the concatenation of the URL-safe base64 encoded
// header and body.
const unsignedToken = .....;

// Sign the |unsignedToken| using ES256 (SHA-256 over ECDSA).
const key = {
  kty: 'EC',
  crv: 'P-256',
  x: window.uint8ArrayToBase64Url(
    applicationServerKeys.publicKey.subarray(1, 33)),
  y: window.uint8ArrayToBase64Url(
    applicationServerKeys.publicKey.subarray(33, 65)),
  d: window.uint8ArrayToBase64Url(applicationServerKeys.privateKey),
};

// Sign the |unsignedToken| with the server's private key to generate
// the signature.
return crypto.subtle.importKey('jwk', key, {
  name: 'ECDSA', namedCurve: 'P-256',
}, true, ['sign'])
.then((key) => {
  return crypto.subtle.sign({
    name: 'ECDSA',
    hash: {
      name: 'SHA-256',
    },
  }, key, utf8Encoder.encode(unsignedToken));
})
.then((signature) => {
  console.log('Signature: ', signature);
});

Un servizio push può convalidare un JWT utilizzando la chiave pubblica del server dell'applicazione per decriptare la firma e assicurarsi che la stringa decriptata sia uguale al "token non firmato", ovvero le prime due stringhe nel JWT.

Il JWT firmato (ovvero tutte e tre le stringhe unite da punti) viene inviato al servizio web push sotto forma di intestazione Authorization con WebPush all'inizio, in questo modo:

Authorization: 'WebPush [JWT Info].[JWT Data].[Signature]';

Il protocollo web push dichiara inoltre che la chiave pubblica del server dell'applicazione deve essere inviata nell'intestazione Crypto-Key come stringa codificata in base64 sicura per l'URL con l'aggiunta di p256ecdsa=.

Crypto-Key: p256ecdsa=[URL Safe Base64 Public Application Server Key]

The Payload Encryption

Ora vediamo come inviare un payload con un messaggio push in modo che, quando la nostra app web riceve un messaggio push, possa accedere ai dati che riceve.

Chi ha utilizzato altri servizi push spesso chiede: perché il payload push web deve essere criptato? Con le app native, i messaggi push possono inviare dati come testo normale.

Uno degli aspetti più interessanti del web push è che tutti i servizi push utilizzano la stessa API (il protocollo web push), pertanto gli sviluppatori non devono preoccuparsi di quale sia il servizio push. Possiamo inviare una richiesta nel formato giusto e aspettarsi che venga inviato un messaggio push. Lo svantaggio di questo approccio è che gli sviluppatori potrebbero inviare messaggi a un servizio push non affidabile. Se cripta il payload, un servizio push non è in grado di leggere i dati inviati. Solo il browser può decriptare le informazioni. In questo modo i dati dell'utente sono protetti.

La crittografia del payload è definita nella specifica di Message Encryption.

Prima di esaminare i passaggi specifici per criptare un payload dei messaggi push, dovremmo esaminare alcune tecniche che verranno utilizzate durante il processo di crittografia. (Un massiccio suggerimento per il cappello a Mat Scales per il suo eccellente articolo sulla crittografia push.)

ECDH e HKDF

Sia ECDH che HKDF vengono utilizzati durante l'intero processo di crittografia e offrono vantaggi per la crittografia delle informazioni.

ECDH: scambio di chiavi Diffie-Hellman con curva ellittica

Immagina di avere due persone che vogliono condividere informazioni, Alice e Bob. Sia Alice che Roberto hanno le proprie chiavi pubbliche e private. Alice e Bob condividono tra loro le loro chiavi pubbliche.

L'utile proprietà delle chiavi generate con ECDH è che Alice può utilizzare la sua chiave privata e la chiave pubblica di Roberto per creare il valore secret "X". Roberto può fare lo stesso, utilizzando la sua chiave privata e la chiave pubblica di Alice per creare in modo indipendente lo stesso valore "X". In questo modo "X" diventa un segreto condiviso e Alice e Bob devono solo condividere la chiave pubblica. Ora Bob e Alice possono usare la "X" per criptare e decriptare i messaggi tra loro.

ECDH, per quanto mi è dato di sapere, definisce le proprietà delle curve che consentono questa "caratteristica" della creazione di un secret condiviso "X".

Questa è una spiegazione generale di ECDH. Per saperne di più, ti consigliamo di guardare questo video.

In termini di codice, la maggior parte dei linguaggi e delle piattaforme sono dotate di librerie che semplificano la generazione di queste chiavi.

Nel nodo eseguiremmo quanto segue:

const keyCurve = crypto.createECDH('prime256v1');
keyCurve.generateKeys();

const publicKey = keyCurve.getPublicKey();
const privateKey = keyCurve.getPrivateKey();

HKDF: funzione di derivazione chiave basata su HMAC

Wikipedia ha una breve descrizione di HKDF:

HKDF è una funzione di derivazione della chiave basata su HMAC che trasforma qualsiasi materiale chiave debole in materiale con chiave crittografica efficace. Può essere utilizzato, ad esempio, per convertire i secret condivisi condivisi da Diffie Hellman in materiale della chiave adatto all'utilizzo per la crittografia, il controllo dell'integrità o l'autenticazione.

Essenzialmente, HKDF prenderà input non particolarmente sicuri e li renderà più sicuri.

La specifica che definisce questa crittografia richiede l'uso di SHA-256 come algoritmo di hash e le chiavi risultanti per HKDF nel push web non devono superare i 256 bit (32 byte).

Nel nodo, questo potrebbe essere implementato in questo modo:

// Simplified HKDF, returning keys up to 32 bytes long
function hkdf(salt, ikm, info, length) {
  // Extract
  const keyHmac = crypto.createHmac('sha256', salt);
  keyHmac.update(ikm);
  const key = keyHmac.digest();

  // Expand
  const infoHmac = crypto.createHmac('sha256', key);
  infoHmac.update(info);

  // A one byte long buffer containing only 0x01
  const ONE_BUFFER = new Buffer(1).fill(1);
  infoHmac.update(ONE_BUFFER);

  return infoHmac.digest().slice(0, length);
}

Suggerimento per cappello nell'articolo di Mat Scale per questo codice di esempio.

Questo testo copre senza limitazioni ECDH e HKDF.

ECDH è un modo sicuro per condividere chiavi pubbliche e generare un secret condiviso. HKDF è un modo per prendere materiale non sicuro e renderlo sicuro.

che verrà utilizzato durante la crittografia del nostro payload. Adesso vediamo cosa prendiamo come input e come vengono criptati.

nascosti

Quando vogliamo inviare un messaggio push a un utente con un payload, sono necessari tre input:

1. Il payload stesso.
2. Il secret auth di PushSubscription.
3. La chiave p256dh di PushSubscription.

Abbiamo notato che i valori auth e p256dh vengono recuperati da PushSubscription. Ti ricordiamo però che, dato un abbonamento, avremmo bisogno di questi valori:

subscription.toJSON().keys.auth;
subscription.toJSON().keys.p256dh;

subscription.getKey('auth');
subscription.getKey('p256dh');

Il valore auth deve essere trattato come un secret e non condiviso all'esterno dell'applicazione.

La chiave p256dh è una chiave pubblica e a volte è indicata come chiave pubblica del client. In questo caso, faremo riferimento a p256dh come chiave pubblica dell'abbonamento. La chiave pubblica dell'abbonamento viene generata dal browser. Il browser conserverà il secret della chiave privata e lo utilizzerà per decriptare il payload.

Questi tre valori, auth, p256dh e payload, sono necessari come input e il risultato del processo di crittografia sarà il payload criptato, un valore di sale e una chiave pubblica utilizzata solo per la crittografia dei dati.

Sali

Il sale deve contenere 16 byte di dati casuali. In NodeJS, dobbiamo creare un sale nel seguente modo:

const salt = crypto.randomBytes(16);

Chiavi pubbliche / private

Le chiavi pubbliche e private dovrebbero essere generate utilizzando una curva ellittica P-256, cosa che eseguiremmo in Node in questo modo:

const localKeysCurve = crypto.createECDH('prime256v1');
localKeysCurve.generateKeys();

const localPublicKey = localKeysCurve.getPublicKey();
const localPrivateKey = localKeysCurve.getPrivateKey();

Ci riferiremo a queste chiavi come "chiavi locali". Vengono utilizzati solo per la crittografia e non hanno nulla a che fare con le chiavi server delle applicazioni.

Con il payload, il secret di autenticazione e la chiave pubblica dell'abbonamento come input e con un sale e un set di chiavi locali appena generati, siamo pronti a eseguire effettivamente la crittografia.

Secret condiviso

Il primo passaggio consiste nel creare un secret condiviso utilizzando la chiave pubblica dell'abbonamento e la nostra nuova chiave privata (ricordi la spiegazione ECDH con Alice e Bob? È semplicissimo).

const sharedSecret = localKeysCurve.computeSecret(
  subscription.keys.p256dh,
  'base64',
);

Questa viene utilizzata nel passaggio successivo per calcolare la chiave pseudo casuale (PRK).

Chiave pseudo casuale

La chiave pseudo casuale (PRK) è la combinazione del secret di autenticazione della sottoscrizione push e del secret condiviso che abbiamo appena creato.

const authEncBuff = new Buffer('Content-Encoding: auth\0', 'utf8');
const prk = hkdf(subscription.keys.auth, sharedSecret, authEncBuff, 32);

Forse ti starai chiedendo a cosa serve la stringa Content-Encoding: auth\0. In breve, non ha uno scopo chiaro, anche se i browser potrebbero decifrare un messaggio in arrivo e cercare la codifica dei contenuti prevista. \0 aggiunge un byte con valore 0 alla fine del buffer. Questo è previsto dai browser che decriptano il messaggio, che si aspettano così tanti byte per la codifica dei contenuti, seguiti da un byte con valore 0 e dai dati criptati.

La nostra chiave pseudo casuale esegue semplicemente l'autenticazione, il secret condiviso e un'informazione di codifica tramite HKDF (ovvero, rendendola più efficace a livello di crittografia).

Il contesto

Il "contesto" è un insieme di byte utilizzato per calcolare in un secondo momento due valori nel browser di crittografia. È essenzialmente un array di byte contenenti la chiave pubblica dell'abbonamento e la chiave pubblica locale.

const keyLabel = new Buffer('P-256\0', 'utf8');

// Convert subscription public key into a buffer.
const subscriptionPubKey = new Buffer(subscription.keys.p256dh, 'base64');

const subscriptionPubKeyLength = new Uint8Array(2);
subscriptionPubKeyLength[0] = 0;
subscriptionPubKeyLength[1] = subscriptionPubKey.length;

const localPublicKeyLength = new Uint8Array(2);
subscriptionPubKeyLength[0] = 0;
subscriptionPubKeyLength[1] = localPublicKey.length;

const contextBuffer = Buffer.concat([
  keyLabel,
  subscriptionPubKeyLength.buffer,
  subscriptionPubKey,
  localPublicKeyLength.buffer,
  localPublicKey,
]);

Il buffer di contesto finale è un'etichetta, ovvero il numero di byte nella chiave pubblica dell'abbonamento, seguito dalla chiave stessa, quindi dal numero di byte della chiave pubblica locale e dalla chiave stessa.

Con questo valore di contesto possiamo utilizzarlo nella creazione di un nonce e di una chiave di crittografia del contenuto (CEK).

Chiave e nonce di crittografia dei contenuti

Un nonce è un valore che impedisce la ripetizione degli attacchi perché dovrebbe essere usato una sola volta.

La chiave di crittografia del contenuto (CEK) è la chiave che verrà infine utilizzata per criptare il nostro payload.

Per prima cosa dobbiamo creare i byte di dati per il nonce e CEK, che è semplicemente una stringa di codifica dei contenuti seguita dal buffer di contesto che abbiamo appena calcolato:

const nonceEncBuffer = new Buffer('Content-Encoding: nonce\0', 'utf8');
const nonceInfo = Buffer.concat([nonceEncBuffer, contextBuffer]);

const cekEncBuffer = new Buffer('Content-Encoding: aesgcm\0');
const cekInfo = Buffer.concat([cekEncBuffer, contextBuffer]);

Queste informazioni vengono acquisite tramite HKDF, combinando il sale e il PRK con i nonceInfo e cekInfo:

// The nonce should be 12 bytes long
const nonce = hkdf(salt, prk, nonceInfo, 12);

// The CEK should be 16 bytes long
const contentEncryptionKey = hkdf(salt, prk, cekInfo, 16);

Questo ci fornisce la nostra chiave di crittografia dei contenuti e del nonce.

Eseguire la crittografia

Ora che abbiamo la nostra chiave di crittografia dei contenuti, possiamo criptare il payload.

Creiamo una crittografia AES128 utilizzando la chiave di crittografia dei contenuti come chiave e il nonce è un vettore di inizializzazione.

In Node, questa operazione viene eseguita in questo modo:

const cipher = crypto.createCipheriv(
  'id-aes128-GCM',
  contentEncryptionKey,
  nonce,
);

Prima di criptare il payload, dobbiamo definire la spaziatura interna che vogliamo aggiungere all'inizio del payload. Il motivo per cui vorremmo aggiungere la spaziatura interna è che impedisce il rischio che i intercettatori siano in grado di determinare i "tipi" di messaggi in base alle dimensioni del payload.

Devi aggiungere due byte di spaziatura interna per indicare la lunghezza di eventuale spaziatura interna aggiuntiva.

Ad esempio, se non hai aggiunto spaziatura interna, avresti due byte con valore 0, ovvero non esiste alcuna spaziatura interna, dopo questi due byte leggerai il payload. Se hai aggiunto 5 byte di spaziatura interna, i primi due byte avranno un valore pari a 5, quindi il consumer leggerà altri 5 byte e inizierà a leggere il payload.

const padding = new Buffer(2 + paddingLength);
// The buffer must be only zeros, except the length
padding.fill(0);
padding.writeUInt16BE(paddingLength, 0);

Eseguiamo quindi la spaziatura interna e il payload attraverso questa crittografia.

const result = cipher.update(Buffer.concat(padding, payload));
cipher.final();

// Append the auth tag to the result -
// https://nodejs.org/api/crypto.html#crypto_cipher_getauthtag
const encryptedPayload = Buffer.concat([result, cipher.getAuthTag()]);

Ora abbiamo il nostro payload criptato. Benissimo!

Non ti resta che determinare in che modo questo payload verrà inviato al servizio push.

Intestazioni e corpo del payload criptati

Per inviare questo payload criptato al servizio push, dobbiamo definire alcune intestazioni diverse nella nostra richiesta POST.

Intestazione crittografia

L'intestazione "Crittografia" deve contenere il valore salt utilizzato per criptare il payload.

Il sale da 16 byte deve essere codificato in modo sicuro nell'URL Base64 e aggiunto all'intestazione Encryption, in questo modo:

Encryption: salt=[URL Safe Base64 Encoded Salt]

Intestazione Crypto-Key

Abbiamo notato che l'intestazione Crypto-Key viene utilizzata nella sezione "Chiavi server di applicazioni" per contenere la chiave pubblica del server delle applicazioni.

Questa intestazione viene utilizzata anche per condividere la chiave pubblica locale utilizzata per criptare il payload.

L'intestazione risultante ha il seguente aspetto:

Crypto-Key: dh=[URL Safe Base64 Encoded Local Public Key String]; p256ecdsa=[URL Safe Base64 Encoded Public Application Server Key]

Tipo di contenuti, lunghezza e codifica delle intestazioni

L'intestazione Content-Length indica il numero di byte nel payload criptato. Le intestazioni "Content-Type" e "Content-Encoding" sono valori fissi. come illustrato di seguito.

Content-Length: [Number of Bytes in Encrypted Payload]
Content-Type: 'application/octet-stream'
Content-Encoding: 'aesgcm'

Con queste intestazioni impostate, dobbiamo inviare il payload criptato come corpo della nostra richiesta. Tieni presente che Content-Type è impostato su application/octet-stream. Questo perché il payload criptato deve essere inviato sotto forma di flusso di byte.

In NodeJS, dovremmo fare così:

const pushRequest = https.request(httpsOptions, function(pushResponse) {
pushRequest.write(encryptedPayload);
pushRequest.end();

Altre intestazioni?

Abbiamo esaminato le intestazioni utilizzate per le chiavi JWT / del server delle applicazioni (ovvero come identificare l'applicazione con il servizio push) e abbiamo parlato delle intestazioni utilizzate per inviare un payload criptato.

Esistono intestazioni aggiuntive utilizzate dai servizi di push per modificare il comportamento dei messaggi inviati. Alcune di queste intestazioni sono obbligatorie, mentre altre sono facoltative.

Intestazione TTL

Obbligatorio

TTL (o durata) è un numero intero che specifica il numero di secondi in cui il messaggio push deve essere pubblicato sul servizio push prima di essere recapitato. Alla scadenza di TTL, il messaggio verrà rimosso dalla coda del servizio push e non verrà recapitato.

TTL: [Time to live in seconds]

Se imposti un valore TTL pari a zero, il servizio push tenterà di recapitare il messaggio immediatamente, ma se il dispositivo non può essere raggiunto, il messaggio verrà immediatamente eliminato dalla coda del servizio push.

Tecnicamente, un servizio push può ridurre il TTL di un messaggio push, se lo desidera. Per capire se ciò è avvenuto, esamina l'intestazione TTL nella risposta di un servizio push.

Argomento

Facoltativo

Gli argomenti sono stringhe che possono essere utilizzate per sostituire i messaggi in attesa con uno nuovo se hanno nomi di argomento corrispondenti.

Questa funzionalità è utile negli scenari in cui vengono inviati più messaggi mentre un dispositivo è offline e vuoi che l'utente veda il messaggio più recente solo quando il dispositivo è acceso.

Urgenza

Facoltativo

L'urgenza indica al servizio push quanto sia importante un messaggio per l'utente. Questa funzionalità può essere utilizzata dal servizio push per preservare la durata della batteria del dispositivo dell'utente, attivando la ricezione di messaggi importanti solo quando la batteria è in esaurimento.

Il valore dell'intestazione è definito come mostrato di seguito. Il valore predefinito è normal.

Urgency: [very-low | low | normal | high]

Tutto insieme

Se hai altre domande su come funziona, puoi sempre vedere in che modo le librerie attivano i messaggi push sull'organizzazione web-push-libs.

Una volta che hai un payload criptato e le intestazioni riportate sopra, devi solo effettuare una richiesta POST a endpoint in un PushSubscription.

Cosa dobbiamo fare con la risposta a questa richiesta POST?

Risposta dal servizio push

Dopo aver inviato una richiesta a un servizio push, devi controllare il codice di stato della risposta, che indicherà se la richiesta è andata a buon fine o meno.

Codice di stato	Descrizione
201	Creata. La richiesta di invio di un messaggio push è stata ricevuta e accettata.
429	Troppe richieste. Questo significa che il server delle applicazioni ha raggiunto un limite di frequenza con un servizio push. Il servizio push deve includere un'intestazione "Riprova-Dopo" per indicare quanto tempo deve passare prima che sia possibile effettuare un'altra richiesta.
400	Richiesta non valida. In genere, ciò significa che una delle intestazioni non è valida o non è formattata correttamente.
404	Non trovato. Questo indica che l'abbonamento è scaduto e non può essere utilizzato. In questo caso devi eliminare "PushSubscription" e attendere che il client sottoscriva di nuovo l'utente.
410	Finito. La sottoscrizione non è più valida e deve essere rimossa dal server delle applicazioni. Questo può essere riprodotto chiamando "unsubscribe()" su un "PushSubscription".
413	Dimensioni del payload troppo grandi. Le dimensioni minime del payload che un servizio push deve supportare sono di 4096 byte (o 4 kB).

Passaggi successivi

• Panoramica delle notifiche push web
• Come funziona Push
• Iscrizione di un utente
• UX delle autorizzazioni
• Invio di messaggi con librerie web push
• protocollo web push
• Gestione degli eventi push
• Visualizzazione di una notifica
• Comportamento di notifica
• Pattern di notifica comuni
• Domande frequenti sulle notifiche push
• Problemi comuni e segnalazione di bug

Codelab

• Crea un client di notifiche push
• Crea un server di notifiche push