Il protocollo Web Push

Abbiamo visto come una libreria può essere utilizzata per attivare i messaggi push, ma cosa fanno esattamente queste librerie?

Sta effettuando richieste di rete, garantendo al contempo che siano nel formato giusto. La specifica che definisce questa richiesta di rete Web Push Protocol.

Questa sezione illustra in che modo il server può identificarsi con le chiavi del server di applicazioni e in che modo vengono inviati il payload criptato e i dati associati.

Non si tratta di un bel lato del push web e non ho esperienza in fatto di crittografia, ma diamo un'occhiata ogni parte, poiché è utile sapere cosa fanno dietro le quinte.

Chiavi del server delle applicazioni

Quando un utente si abbona, viene passato un applicationServerKey. Questa chiave viene passata al servizio push e utilizzata per verificare che l'applicazione che ha sottoscritto l'abbonamento dell'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.)

Che cosa significa tutto questo e cosa succede esattamente? Bene, questi sono i passaggi seguiti autenticazione server delle applicazioni:

1. Il server dell'applicazione firma alcune informazioni JSON con la propria chiave dell'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 archiviata che ha ricevuto pushManager.subscribe() per verificare che le informazioni ricevute siano firmate da la chiave privata relativa alla chiave pubblica. Ricorda: la chiave pubblica è applicationServerKey passato alla chiamata di sottoscrizione.
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. Tieni presente la legenda in basso a sinistra che indica le chiavi pubbliche e private.

Le "informazioni firmate" aggiunto a un'intestazione nella richiesta è un token web JSON.

Token web JSON

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

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

Su https://jwt.io/ sono disponibili diverse librerie che possono eseguire la firma per te e ti consiglio di farlo, se possibile. Per completezza, vediamo come creare manualmente un JWT firmato.

Web push e JWT firmati

Un JWT firmato è solo una stringa, anche se può essere considerato come un insieme di tre stringhe per punti.

La prima e la seconda stringa (informazioni JWT e dati JWT) sono parti JSON che è stato codificato in base64, il che significa che è leggibile pubblicamente.

La prima stringa contiene informazioni sul token JWT stesso e indica l'algoritmo utilizzato per creare la firma.

Le informazioni JWT per le notifiche web devono contenere le seguenti informazioni:

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

La seconda stringa è i dati JWT. In questo modo vengono fornite informazioni sul mittente del JWT, che è destinato e per quanto tempo è valido.

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

{
  "aud": "https://some-push-service.org",
  "exp": "1469618703",
  "sub": "mailto:example@web-push-book.org"
}

Il valore aud è il "pubblico", ovvero a chi è destinato il JWT. Per il web, esegui il push è il servizio push, pertanto lo impostiamo sull'origine del push Google Cloud.

Il valore exp è la data di scadenza del JWT, che impedisce agli autori di intrusioni di riutilizzare un JWT se lo intercettano. La scadenza è un timestamp in secondi e non deve superare le 24 ore.

In Node.js la scadenza viene impostata utilizzando:

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

Sono 12 ore anziché 24 per evitare eventuali problemi con le 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, può trovare le informazioni di contatto del JWT. (Questo è il motivo per cui la libreria web-push aveva bisogno di un indirizzo email).

Proprio come le informazioni JWT, i dati JWT sono codificati come base sicura per gli URL64 stringa.

La terza stringa, la firma, è il risultato dell'unione delle prime due stringhe (JWT Info e JWT Data) con un carattere punto, che chiameremo "token non firmato", e della firma.

Il processo di firma richiede la crittografia del "token non firmato" utilizzando ES256. Secondo la specifica JWT, ES256 è l'abbreviazione di "ECDSA che utilizza la curva P-256 e l'algoritmo di hashing SHA-256". Utilizzando la crittografia web, puoi creare la firma nel seguente 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 server delle applicazioni pubblica per decriptare la firma e assicurarsi che la stringa decriptata sia la stessa come "token non firmato" (ovvero le prime due stringhe nel JWT).

Il JWT firmato (ovvero tutte e tre le stringhe unite da puntini) viene inviato al servizio push web come intestazione Authorization con WebPush anteposto, come segue:

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

Il protocollo Web Push stabilisce inoltre che la chiave del server di applicazioni pubblico deve essere inviata nell'intestazione Crypto-Key come stringa con codifica Base64 sicura per l'URL con p256ecdsa= anteposto.

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

La crittografia del payload

Vediamo ora come inviare un payload con un messaggio push in modo che, quando la nostra app web lo riceve, possa accedere ai dati ricevuti.

Chi ha utilizzato altri servizi push spesso pone una domanda comune: perché il web esegue il push il payload debba essere criptato? Con le app native, i messaggi push possono inviare dati come testo normale.

Uno dei vantaggi delle notifiche push web è che, poiché tutti i servizi push utilizzano la stessa API (il protocollo push web), gli sviluppatori non devono preoccuparsi di chi sia il servizio push. Possiamo inviare una richiesta nel formato corretto e aspettarci che venga inviato un messaggio push. Lo svantaggio è che gli sviluppatori potrebbero inviare messaggi a un servizio push non attendibile. Se il payload viene criptato, un servizio push non può leggere i dati inviati. Solo il browser può decriptare le informazioni. In questo modo vengono protetti i dati dell'utente.

La crittografia del payload è definita nel documento Message Encryption (Crittografia dei messaggi) del modello.

Prima di esaminare i passaggi specifici per criptare il payload dei messaggi push, dobbiamo esaminare alcune tecniche che verranno utilizzate durante il processo di crittografia. (L'enorme punta del cappello a Mat Scales per il suo eccellente articolo sulla encryption.)

ECDH e HKDF

Sia ECDH che HKDF vengono utilizzati durante il processo di crittografia e offrono vantaggi ai fini della crittografia delle informazioni.

ECDH: scambio di chiavi Diffie-Hellman a curva ellittica

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

L'utile proprietà delle chiavi generate con ECDH è che Alice può utilizzare e la chiave pubblica di Roberto per creare il valore del secret "X". Bob 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 hanno dovuto condividere solo la loro chiave pubblica. Ora Bob e Alice possono usare "X" per criptare e decriptare i messaggi tra loro.

Per quanto mi risulta, la crittografia ECDH definisce le proprietà delle curve che consentono questa "funzionalità" di creare una chiave segreta condivisa "X".

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

In termini di codice, la maggior parte dei linguaggi / piattaforme ha librerie per è facile generare queste chiavi.

Nel nodo, eseguiremmo queste operazioni:

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

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

HKDF: funzione di derivazione della chiave basata su HMAC

Wikipedia contiene una breve descrizione di HKDF:

HKDF è una funzione di derivazione delle chiavi basata su HMAC che trasforma qualsiasi materiale della chiave debole in materiale della chiave crittograficamente sicuro. Può essere usato, ad esempio, esempio, per convertire Diffie Hellman ha scambiato i segreti condivisi in materiale delle chiavi adatte all'uso per la crittografia, il controllo dell'integrità o l'autenticazione.

In sostanza, HKDF prende input non particolarmente sicuri e li rende più sicuri.

La specifica che definisce questa crittografia richiede l'utilizzo di SHA-256 come algoritmo hash e le chiavi risultanti per HKDF nel push web non dovrebbero essere più lunghe di 256 bit (32 byte).

Nel nodo 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);
}

Un ringraziamento a Mat Scale per questo codice di esempio.

Questa descrizione copre genericamente ECDH e HKDF.

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

Verrà utilizzato durante la crittografia del payload. Ora vediamo cosa prendiamo e come viene criptato.

Input

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

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

Abbiamo visto che i valori auth e p256dh vengono recuperati da un PushSubscription, ma per un breve promemoria, 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 considerato come un secret e non deve essere condiviso all'esterno dell'applicazione.

La chiave p256dh è una chiave pubblica, talvolta denominata chiave pubblica del client. Qui ci riferiremo a p256dh come alla chiave pubblica dell'abbonamento. Viene generata la chiave pubblica dell'abbonamento dal browser. Il browser manterrà la chiave privata segreta e la utilizzerà per decriptare il payload.

Questi tre valori, auth, p256dh e payload sono necessari come input e il risultato di crittografia è il payload criptato, un valore di sale e una chiave pubblica la crittografia dei dati.

Sale

Il sale deve essere costituito da 16 byte di dati casuali. In NodeJS, per creare un sale, eseguiremo i seguenti passaggi:

const salt = crypto.randomBytes(16);

Chiavi pubbliche/private

Le chiavi pubblica e privata devono essere generate utilizzando una curva ellittica P-256, come faresti in Node nel seguente 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 sono niente a che fare con le chiavi dei server delle applicazioni.

Con il payload, il segreto di autenticazione e la chiave pubblica di abbonamento come input e con una sale e un set di chiavi locali, siamo pronti a eseguire la crittografia.

Secret condiviso

Il primo passaggio consiste nel creare un secret condiviso utilizzando la chiave pubblica di abbonamento e il nostro nuovo chiave privata (ricordi la spiegazione relativa a ECDH presentata ad Alice e Bob? È semplicissimo.

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

Questo viene utilizzato nel passaggio successivo per calcolare la chiave pseudo casuale (PRK).

Chiave pseudo casuale

La chiave pseudo casuale (PRK) è la combinazione dell'autenticazione della sottoscrizione push e il 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 decriptare un messaggio in arrivo e cercare la codifica dei contenuti prevista. \0 aggiunge un byte con un valore pari a 0 alla fine del buffer. Questo è atteso dai browser che decriptano il messaggio, che si aspettano così tanti byte per la codifica dei contenuti, seguito da un byte con valore 0 e ai dati criptati.

La nostra pseudo chiave casuale esegue semplicemente l'autenticazione, il segreto condiviso e un'informazione di codifica tramite HKDF (ovvero la maggiore sicurezza crittografica).

Contesto

Il "contesto" è un insieme di byte utilizzato per calcolare due valori in un secondo momento del browser. Si tratta essenzialmente di un array di byte contenente 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,
]);

L'ultimo buffer di contesto è un'etichetta, il numero di byte della chiave pubblica dell'abbonamento, seguito dalla chiave stessa, quindi il numero di byte della chiave pubblica locale, seguito dalla chiave stessa.

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

Chiave di crittografia dei contenuti e nonce

nonce è un valore che impedisce la riproduzione perché dovrebbe essere usato una sola volta.

La chiave di crittografia dei contenuti (CEK) è la chiave che verrà utilizzata per criptare il payload.

Per prima cosa dobbiamo creare i byte di dati per il nonce e CEK, che sono semplicemente stringa di codifica 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 gestite tramite HKDF che combina salt e PRK con 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);

In questo modo otteniamo la chiave di crittografia dei contenuti e il nonce.

Esegui 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 nel seguente modo:

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

Prima di criptare il nostro payload, dobbiamo definire la quantità di spaziatura interna che vogliamo da aggiungere alla parte anteriore del payload. Il motivo per cui dovremmo aggiungere spaziatura interna è che previene il rischio che le intercettazioni siano in grado di determinare "tipi" di messaggi in base alle dimensioni del payload.

Devi aggiungere due byte di spaziatura interna per indicare la lunghezza di eventuali spaziature interne aggiuntive.

Ad esempio, se non hai aggiunto spaziatura interna, avrai 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, i primi due byte avranno un valore di 5, quindi il consumatore leggerà altri cinque byte e poi 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);

Quindi eseguiamo 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 payload criptato. Benissimo!

Non resta che determinare come questo payload viene inviato al servizio push.

Intestazioni di payload crittografati corpo

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

Intestazione di crittografia

La sezione "Crittografia" deve contenere il salt utilizzato per criptare il payload.

Il sale di 16 byte deve essere codificato in base64 sicuro per il web e aggiunto all'intestazione Encryption, come segue:

Encryption: salt=[URL Safe Base64 Encoded Salt]

Intestazione Crypto-Key

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

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 intestazioni

L'intestazione Content-Length indica il numero di byte nell'elenco per il payload. Le intestazioni "Content-Type" e "Content-Encoding" sono valori fissi. come mostrato 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 della nostra richiesta. Nota che Content-Type è impostato su application/octet-stream. Questo perché il payload criptato deve essere inviato come stream di byte.

In NodeJS seguiamo questa procedura:

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

Altre intestazioni?

Abbiamo esaminato le intestazioni utilizzate per le chiavi JWT / Application Server (ovvero come identificare con il servizio push) e abbiamo esaminato le intestazioni utilizzate per inviare un messaggio per il payload.

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

Intestazione TTL

Obbligatorio

TTL (o TTL, time to live) è un numero intero che specifica il numero di secondi che vuoi che il messaggio push rimanga attivo nel servizio push prima di essere inviato. Alla scadenza del token 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 inviare immediatamente il messaggio, ma se il dispositivo non è raggiungibile, il messaggio verrà eliminato immediatamente dalla coda del servizio push.

Tecnicamente, un servizio push può ridurre il TTL di un messaggio push se lo vuole. Puoi stabilirlo esaminando l'intestazione TTL in la risposta da un servizio push.

Argomento

Facoltativo

Gli argomenti sono stringhe che possono essere utilizzate per sostituire un messaggio in attesa con un nuovo messaggio se hanno nomi di argomenti corrispondenti.

Questo è utile in scenari in cui vengono inviati più messaggi mentre un dispositivo è offline e vuoi che un utente veda solo l'ultimo messaggio quando il dispositivo è acceso.

Urgenza

Facoltativo

L'urgenza indica al servizio push l'importanza di un messaggio per l'utente. Questo puo essere utilizzato dal servizio push per contribuire a preservare la durata della batteria del dispositivo di un utente risvegliando il dispositivo solo per i messaggi importanti quando la batteria è in esaurimento.

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

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

Tutti insieme

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

Una volta ottenuto un payload criptato e le intestazioni riportate sopra, devi solo inviare una richiesta POST al endpoint in un PushSubscription.

Che 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 ti indica se la richiesta è andata a buon fine o meno.

Codice di stato	Descrizione
201	Creata. La richiesta di inviare un messaggio push è stata ricevuta e accettata.
429	Troppe richieste. Ciò significa che il server delle applicazioni ha raggiunto un limite di frequenza con un servizio push. Il servizio push deve includere un messaggio "Riprova dopo" per indicare quanto tempo deve passare prima che sia possibile effettuare un'altra richiesta.
400	Richiesta non valida. In genere, significa che una delle intestazioni non è valida o è formattata in modo errato.
404	Non trovato. Questo indica che l'abbonamento è scaduto e non possono essere utilizzate. In questo caso, devi eliminare "PushSubscription" e attendere che il client riabboni l'utente.
410	addio. L'abbonamento non è più valido e deve essere rimosso dal server delle applicazioni. Può essere riprodotto richiamando "unsubscribe()" su "PushSubscription".
413	Dimensioni del payload troppo grandi. Le dimensioni minime del payload che un servizio push deve supportare sono 4096 byte (o 4 KB).

Per ulteriori informazioni sui codici di stato HTTP, puoi anche leggere lo standard Web Push (RFC8030).

Passaggi successivi

• Panoramica delle notifiche push web
• Come funzionano le notifiche push
• Iscrizione di un utente
• UX per le autorizzazioni
• Invio di messaggi con le librerie Web Push
• Protocollo push web
• Gestione degli eventi push
• Visualizzazione di una notifica
• Comportamento delle notifiche
• Pattern di notifica comuni
• Domande frequenti sulle notifiche push
• Problemi comuni e bug dei report

Codelab

• Creare un client di notifiche push
• Creare un server di notifiche push