Le notifiche iOS possono perdere l'autorizzazione di push se l'utente è attualmente attivo

Bug
1

Le notifiche iOS possono perdere il permesso di push se la notifica viene soppressa. Il codice di Discourse è configurato per sopprimere facoltativamente le notifiche e, di conseguenza, perderà il permesso di push quando ciò accade tre volte.

Ecco il codice per il service worker delle notifiche push.

Questo codice presenta un bug critico, alla riga 178. Lì, il service worker controlla se l’utente è attivo (cioè non inattivo). In tal caso, l’evento push restituisce false senza mostrare una notifica.

(Controlla anche payload.hide_when_active, ma a quanto pare hide_when_active è sempre true, e quindi questo codice restituisce sempre false quando l’utente è attivo.)

Apple vieta i push silenziosi, revocando il permesso di push dopo tre eventi che non mostrano notifiche

Ciò non è accettabile secondo le regole di Apple per le notifiche push.

Potenza e privacy

Sia il progetto open source WebKit che Apple trattano la privacy come un diritto umano fondamentale. Come per altre funzionalità privilegiate della piattaforma web, la richiesta di un abbonamento push richiede un gesto esplicito dell’utente. Richiede inoltre di impostare il flag userVisibleOnly su true e di mantenere tale promessa mostrando sempre una notifica in risposta a un messaggio push.

L’API Web Push non è un invito per un runtime silenzioso in background, poiché ciò violerebbe la fiducia di un utente e influirebbe sulla durata della batteria dell’utente.

Le violazioni della promessa userVisibleOnly comporteranno la revoca di un abbonamento push.

(enfasi mia)

Questo è spiegato più in dettaglio nel video WWDC di Apple su Web Push, a 9:57

Notare che stiamo esplicitamente affermando che promettiamo di rendere sempre visibili all’utente i push. Mentre lo standard per l’API JavaScript Push accetta facoltativamente runtime JavaScript silenziosi in risposta a un push, la maggior parte dei browser non lo supporta. Safari non lo supporta.

… e poi a 13:35:

Come menzionato quando vi ho mostrato il codice su come richiedere un abbonamento push, dovete promettere che i push saranno visibili all’utente. La gestione di un evento push non è un invito per il vostro JavaScript a ottenere un runtime silenzioso in background. Farlo violerebbe sia la fiducia dell’utente che la durata della batteria dell’utente. Quando si gestisce un evento push, è effettivamente necessario pubblicare una notifica nel Centro Notifiche. Altri browser hanno contromisure contro la violazione della promessa di rendere i push visibili all’utente, e così anche Safari. Nella build beta di macOS Ventura, dopo tre eventi push in cui non si riesce a pubblicare una notifica in modo tempestivo, l’abbonamento push del tuo sito verrà revocato. Dovrai ripetere il flusso di autorizzazione.

(enfasi mia)

Apple consiglia di mostrare le notifiche immediatamente, non dopo la chiusura delle notifiche

Il codice consigliato da Apple è simile a questo, a 11:39:

self.addEventListener('push', (event) => {
    let pushMessageJSON = event.data.json();

    // Il nostro server inserisce tutto il necessario per mostrare la notifica
    // nei nostri dati JSON.
    event.waitUntil(self.registration.showNotification(pushMessageJSON.title, {
        body: pushMessageJSON.body,
        tag: pushMessageJSON.tag,
        actions: [{
            action: pushMessageJSON.actionURL,
            title: pushMessageJSON.actionTitle,
        }]
    }));
}

Ricordate come, quando ci siamo abbonati ai push, il nostro JavaScript ha promesso che sarebbero sempre stati visibili all’utente? Ciò significa che dobbiamo sempre mostrare una notifica nativa della piattaforma in risposta a ogni push. È meglio farlo il prima possibile nel gestore dell’evento push.

Il codice di Discourse non segue la best practice raccomandata. Il codice di Discourse prima chiude tutte le notifiche e solo dopo mostra una notifica.

Discourse dovrebbe sempre chiamare showNotification in risposta a un evento push, e dovrebbe sempre farlo il prima possibile.

8 Mi Piace
2

@Falco / @featheredtoast cosa ne pensate?

Che impatto avrebbe la rimozione sia del controllo di chiusura che di quello di inattività?

Nel complesso, non sono affatto sicuro di questo controllo di inattività, mi sembra che stia solo creando confusione.

Nel peggiore dei casi, se lo richiediamo su Android o Desktop (non Safari), possiamo sempre aggiungere una condizione qui, ma la mia sensazione è che dovremmo semplicemente rimuovere il codice qui.

Eccellente debug @dfabulich :hugs:

3 Mi Piace
4

Noto che va bene fare la chiusura, immagino, purché venga fatta dopo aver chiamato showNotification.

… ma onestamente non vedo il senso di chiudere le notifiche. Tanto vale lasciarle accumulare nel vassoio delle notifiche, secondo me.

Nota: Questa API non dovrebbe essere utilizzata solo per rimuovere la notifica dallo schermo dopo un intervallo di tempo fisso, poiché questo metodo rimuoverà la notifica anche da qualsiasi vassoio delle notifiche, impedendo agli utenti di interagire con essa dopo che è stata inizialmente mostrata. Un uso valido per questa API sarebbe quello di rimuovere una notifica che non è più rilevante (ad esempio, l’utente ha già letto la notifica sulla pagina web nel caso di un’app di messaggistica o la canzone successiva è già in riproduzione in un’app musicale).

3 Mi Piace
5

Da quello che ho letto su questo argomento durante il fine settimana, non possiamo nemmeno usare async/promises nel gestore di eventi push, dobbiamo mostrarlo al più presto o Apple revocherà i tuoi diritti di notifica.

Tutto ciò è in linea con quello che dice @dfabulich.

Penso che stiamo essendo troppo “intelligenti” per il nostro bene, dovremmo effettivamente rimuovere tutti i controlli e mostrare semplicemente la notifica.

6 Mi Piace
6

Non posso ringraziarti abbastanza @dfabulich per averlo scoperto!

3 Mi Piace
7

OK, ho un PR per questo.

@Falco / @featheredtoast dovremmo unirlo?

Se dobbiamo saltare le notifiche push, dobbiamo farlo sul server, non sul client. La logica di collasso è sempre stata in qualche modo discutibile, le app tendono a non farlo.

2 Mi Piace
8

Ohh sì, ha molto più senso inviare notifiche solo quando devono essere visualizzate. Dovrebbe soffocare notifiche eccessive altrove prima o poi, ma sono a posto con l’unire questo qui :+1:

Riguardo al collasso delle notifiche, è un peccato perderlo ma… idealmente saremmo in grado di fare qualcosa di simile al dismiss automatico di altre app man mano che un utente scorre le notifiche su qualsiasi dispositivo connesso, ma ciò potrebbe richiedere un po’ di lavoro extra. L’intento è lo stesso, ovvero non avere mai un’ondata di notifiche obsolete che si accumulano. Di nuovo, va bene, ma dovremo rivederlo più tardi, a seconda di quanto dolore causi.

2 Mi Piace