Bruno Rosati Matricola

Транскрипт

1

2 Introduzione Le notifiche push sono avvisi che le applicazioni per mobile device inviano alla schermata iniziale del dispositivo stesso quando, generalmente, non si utilizza l'applicazione. La corretta gestione di queste notifiche è determinante al fine di ottenere una qualità maggiore delle informazioni fornite dall applicazione che si intende sviluppare o integrare. Il principio delle notifiche push si basa sul fatto che , servizi di messaggistica istantanea o generiche notizie riguardanti altro genere di applicazioni vengano scaricate senza la precisa richiesta dell utente. Ciò comporta che anche se un applicazione è apparentemente chiusa alcune sue funzioni, in realtà, continuano a lavorare in background consentendo di notificare l arrivo di un nuovo messaggio oppure quali nuovi possibili aggiornamenti dell applicazione siano a disposizione e così via. Quindi viene data all utente l opportunità di non perdersi alcuna informazione pur senza che quest ultimo si sia adoperato in prima persona, dato che le notifiche gli arriveranno direttamente sulla home del suo dispositivo. Queste sono le tre cose che una notifica può fare: - mostrare un breve messaggio; - suono di avviso; - impostare un numero nel badge dell icona dell applicazione. Queste tre funzioni vanno combinate in modo tale che l applicazione renda al meglio.

3 Panoramica generale Schema rappresentativo del funzionamento di tutto il sistema push. Le notifiche push vengono abilitate dall app. La ricezione di queste notifiche dovrà essere confermata dall utente che esprimerà il consenso a riceverle. - L app riceve un token del dispositivo (device token). Si può pensare al token come l indirizzo al quale vengono spedite le notifiche. - L applicazione invia al server il token - Quando succede qualcosa di rilevante, il server invia una notifica all Apple Push Notification Service (APNS, per abbreviare). - APNS invia la notifica al device dell utente.

4 Quando il dispositivo dell utente riceve la notifica mostra un Alert, suona oppure aggiorna il badge dell icona. L utente a questo punto può lanciare direttamente l applicazione che penserà a gestire la notifica, per esempio portando l utente direttamente nella parte dell app interessata. Oltre ad essere un servizio di trasporto semplice ma efficiente e ad alta capacità, APNS include un componente predefinito di qualità del servizio che fornisce funzionalità di store-and-forward. Qualità del servizio Apple Push Notification Service include di default un componente di qualità del servizio (QoS che svolge una funzione store-and-forward. Se APNS deve tentare di inviare una notifica, ma il dispositivo è offline, la notifica viene conservata per un periodo limitato di tempo e consegnata al dispositivo nel momento in cui questo torna disponibile. Solo una notifica recente per una particolare applicazione resta memorizzata. Se più notifiche vengono inviate quando il dispositivo non è in linea, ogni nuova notifica fa sì che la notifica precedente sia scartata. Se il dispositivo rimane offline per un lungo periodo di tempo, le notifiche che venivano conservate per esso vengono scartate. Architettura di sicurezza Per abilitare la comunicazione tra un provider e un dispositivo, Apple Push Notification Service deve fornire alcuni punti di accesso ad essi. Ma per garantire la sicurezza, deve anche regolamentare l'accesso a questi punti di ingresso. A tal fine, APNS richiede due diversi livelli di fiducia per i provider, i device e le loro comunicazioni. Questi sono conosciuti come Connection Trust e Token Trust. Connection Trust stabilisce con certezza che, da un lato, la connessione APNS sia con un fornitore autorizzato, con cui Apple ha accettato di consegnare le notifiche. Dal lato device della connessione, APNS deve certificare che il collegamento sia stabilito con un dispositivo legittimo. Dopo che APNS ha garantito i punti di entrata, deve quindi assicurarsi che trasmetta le notifiche solo a end point legittimi. Per fare ciò, deve convalidare l'instradamento dei messaggi che viaggiano attraverso il trasporto; solo il dispositivo che è il bersaglio designato di notifica dovrebbe riceverlo. In APNS, la garanzia di accurata messaggio di routing (o token trust) è resa possibile attraverso il device token. Il dispositivo condivide il token con il suo provider. Successivamente, questo token accompagna ogni notifica da parte del fornitore. È la base per stabilire che il percorso di una notifica particolare sia legittimo.

5 Service-to-Device Connection Trust APNS stabilisce l'identità di un dispositivo in collegamento attraverso l autenticazione TLS peer-to-peer. Nel corso di questa procedura, un dispositivo avvia una connessione TLS con APNS, che restituisce il proprio certificato da server. Il dispositivo convalida il certificato e poi invia il proprio certificato ad APNS, che a sua volta convalida il certificato. Provider-to-Service Connection Trust La Connection Trust yra un provider e APNS è anch essa stabilita attraverso l autenticazione TLS peer-to-peer. La procedura è simile a quella descritta in Serviceto-Device Connection Trust. Il provider avvia una connessione TLS, ottiene il certificato del server da APNS, e convalida il certificato. Quindi il provider invia il proprio certificato di APNS, che lo convalida al suo termine. Una volta che questa procedura è completa, è stata stabilita una connessione sicura TLS; APNS è ormai sicuro che il collegamento sia stato fatto da un fornitore legittimo.

6 Si noti che il collegamento provider è valido per la consegna di una sola app specifica, identificata dal tema (ID bundle) specificata nel certificato. APNS mantiene anche un elenco di revoche di certificati; se il certificato di un provider è in questo elenco, APNS può revocare provider trust (cioè rifiutare la connessione). Generazione Token e Dispersione Le app devono registrarsi per ricevere le notifiche a distanza; lo si fa in genere subito dopo l'installazione su un dispositivo. Il sistema riceve la richiesta di registrazione dalla app, si collega con APNS, e inoltra la richiesta. APNS genera un device token utilizzando le informazioni contenute nel certificato unico dispositivo. Il device token contiene un identificatore del dispositivo. Viene quindi crittografato il device token attraverso una token key e viene restituito al dispositivo.

7 Il dispositivo restituisce il device token per l'applicazione richiesta come un NSData object. L'applicazione dovrà poi consegnare il device token al suo provider sia in formato binario che esadecimale. La figura sottostante illustra nuovamente la sequenza di generazione token e dispersione, ma mostra inoltre il ruolo della client app nel fornire il suo provider del device token.

8 Token Trust (notifica) Dopo che il sistema ha ottenuto un device token da APNS, deve fornire APNS con il token ogni volta che si collega con esso. APNS decodifica il device token e verifica che il token sia stato generato appositamente per il dispositivo che si sta connettendo. Per convalidare, APNS si assicura che l'identificatore del device, contenute nel token, corrisponda l'identificatore del dispositivo nel certificato del device. Ogni notifica che un provider invia ad APNS per la consegna ad un dispositivo deve essere corredata dal device token ottenuto da un app su quel dispositivo. APNS decodifica il token attraverso la token key, assicurando in tal modo che la notifica sia valida. Successivamente utilizza l'id device, contenuto nel device token, per determinare il dispositivo di destinazione per la notifica.

9 Componenti del Trust Per supportare il modello di sicurezza per APNS, i provider e i device devono possedere determinati certificati, certificati Certificate Authority (CA) o token. Provider: Ogni provider richiede un certificato provider unico e una chiave crittografica privata per verificare che la connessione sia stabilita con APNS. Questo certificato, fornito da Apple, deve identificare il topic specifico pubblicato dal provider; il topic è l'id del pacchetto dell'applicazione client. Per ogni notifica, il provider deve fornire APNS con un token che identifica il dispositivo di destinazione. Il provider può eventualmente voler consentire al servizio che si connette di utilizzare il certificato del server pubblico fornito dal server APNS. Device: il sistema utilizza il certificato server pubblico che ha ricevuto dal APNS per autenticare il servizio che si è connesso ad esso. Ha una chiave privata e il certificato unico che viene utilizzato per autenticarsi al servizio e stabilire la connessione TLS. Ottiene il certificato device e la chiave durante l'attivazione del dispositivo e li memorizza nel Keychain. Il sistema possiede anche il suo specifico device token, che riceve durante il processo di connessione del servizio. Ogni client app registrata è responsabile della consegna di questo token al suo content provider. Server APNS hanno anche i certificati necessari, i certificati CA e chiavi crittografiche (pubbliche e private) per convalidare le connessioni e le identità dei provider e dei device. Il Notification Payload Ogni notifica remota contiene un payload. Il payload contiene le informazioni su come il sistema dovrebbe avvertire l'utente, così come tutti i dati personalizzati forniti. In ios 8 e versioni successive, la dimensione massima consentita per un carico utile di notifica è di 2 kilobyte; Apple Push Notification Service rifiuta ogni notifica che supera questo limite (prima di ios 8 e in OS X, la dimensione massima di carico era di 256 byte). Per ogni notifica, si compone un JSON dictionary object (come definito da RFC 4627). Questo dizionario deve contenere un altro dizionario identificato dalle chiavi aps. Il dizionario aps può contenere una o più proprietà che specificano i seguenti tipi di notifica utente: - un messaggio di avviso da visualizzare all'utente; - un numero distintivo l'icona dell'applicazione chiamante; - un suono da riprodurre.

10 Il dizionario aps può anche contenere la proprietà dei contenuti disponibili. La proprietà contenuti disponibili con un valore pari a 1 consente l'atto di notifica a distanza come una notifica "silenziosa". Quando una notifica silenziosa arriva, ios risveglia l applicazione in background in modo da poter ottenere nuovi dati dal server o far processare delle informazioni in background. Agli utenti non viene comunicato alcunché circa le informazioni nuove o modificate risultanti da una comunicazione silenziosa, ma le possono scoprire la prossima volta che apriranno l applicazione. Per supportare le notifiche remote silenziose, occorre aggiungere remote-notification value alla matrice UIBackgroundModes nel file Info.plist. Se l'applicazione di destinazione non è in esecuzione quando la notifica arriva, il messaggio, il suono, o il valore distintivo di allarme è riprodotto o mostrato. Se l'applicazione è in esecuzione, il sistema fornisce la notifica all applicazione come un oggetto NSDictionary. Il dizionario contiene i corrispondenti Cocoa property-list objects (più NSNull). I provider possono specificare i valori di payload personalizzati al di fuori dell Applereserved aps namespace. Valori personalizzati devono comunque utilizzare strutture JSON e tipi ptimitivi: dizionario (oggetto), array di stringhe, numeri e booleani. Si consiglia di non includere le informazioni sui clienti (o dati sensibili) come dati di payload personalizzati. Invece, si può utilizzare per scopi quali l'impostazione rapida (per l'interfaccia utente) o metriche interne. Qualsiasi azione associata con un messaggio di avviso non dovrebbe essere distruttiva; per esempio, non dovrebbe eliminare dati sul dispositivo.