per studenti e collaboratori SUPSI
Studente/iFlavio Righi
RelatoreAndrea Baldassarri
CorrelatoreNicola Rizzo
CommittenteSUPSI
Corso di laureaProgetto di diploma
ModuloM00002
Anno2107/18
DataIndice
Abstract 1
Contesto del Progetto 3
2.1 Descrizione . . . 3
2.2 Compiti . . . 4
2.3 Tecnologie . . . 4
Introduzione alle tecnologie 7 3.1 Spring & Spring Boot . . . 7
3.2 REST . . . 8 3.2.1 Richieste HTTP . . . 9 3.2.1.1 Metodi HTTP . . . 9 3.2.1.2 Header: . . . 9 3.2.1.3 Path: . . . 11 3.2.1.4 Body: . . . 11 3.2.2 Risposte HTTP . . . 12 3.2.2.1 Response Header: . . . 12 3.2.2.2 Body: . . . 12 3.2.3 CORS . . . 13 3.2.3.1 Simple Request . . . 13 3.2.3.2 Preflight Request . . . 14 3.3 JWT . . . 15 3.4 Ionic e Cordova . . . 17 3.4.1 Nativo vs Ibrido . . . 17 3.4.1.1 Vantaggi e Svantaggi . . . 18 3.5 Docker . . . 18 Progetto 19 4.1 Server . . . 19 4.1.1 Database . . . 19 4.1.2 Accessi . . . 20
4.1.2.1 Login NET-ID . . . 20 4.1.2.2 Long-polling . . . 21 4.1.3 Endpoint REST . . . 23 4.1.4 Struttura classi . . . 25 4.1.5 Interfaccia Backend . . . 27 4.2 Client . . . 28 4.2.1 Grafica . . . 28 4.3 Funzionamento applicazione . . . 30 4.4 Sicurezza . . . 33 4.4.1 Autenticazione server . . . 33 4.4.2 Unicità accesso . . . 34 4.4.3 Autenticazione client . . . 34 4.4.4 Anti-cheating . . . 36 4.4.4.1 Offline . . . 36 4.4.4.2 Autenticità applicazione . . . 37 Conclusioni 39 5.1 Sviluppi futuri . . . 39 Bibliografia 41
Elenco delle figure
1 CORS . . . 14
2 Ionic-cordova . . . 17
3 Database ER schema . . . 20
4 Login Server Side FlowChart . . . 22
5 Diagramma classi utente . . . 25
6 Diagramma classi benefit . . . 26
7 Menù tab applicazione . . . 28
8 Home page applicazione . . . 28
9 Benefit applicazione . . . 29
10 Diagramma di flusso applicazione completa . . . 30
11 Applicazione - login . . . 31
12 Applicazione - nessuna foto . . . 31
13 Applicazione - foto rifiutata . . . 32
14 Applicazione - caricamento completo . . . 32
15 JWT Check Server Side FlowChart . . . 33
16 Flow Chart autenticazione lato client . . . 34
17 Testo animato . . . 37
Abstract
Il progetto punta a realizzare un’applicazione per dispositivi mobili, compatibile con iOS e Android, che permetta a studenti e collaboratori della SUPSI di poter approfittare dei vantaggi offerti dalle carte MySUPSI e MySUPSI Gold senza doverla esibire fisicamente. L’autorizzazione e la scelta della tipologia di carta da mostrare nell’app vengono gestite da un backend. Lo stesso dovrà inoltre occuparsi di fornire all’app una lista di offerte di cui l’utente potrà approfittare.
Contesto del Progetto
2.1
Descrizione
Il progetto, commissionato dalla direzione SUPSI (Scuola Universitaria Professionale della Svizzera Italiana), punta a realizzare un’applicazione per dispositivi mobili, compatibile con iOS e Android, che permetta a studenti e collaboratori SUPSI di poter approfittare dei van-taggi offerti dalle carte MySUPSI e MySUPSI Gold senza doverle esibire fisicamente. Attualmente la tessera viene utilizzata per identificarsi come studente o collaboratore uni-versitario all’interno di aziende sul territorio, in Europa e nel mondo che offrono sconti e promozioni. La lista delle offerte, frutto di accordi tra SUPSI e aziende, è visibile sul sito dell’università.
I possessori della tessera hanno anche l’opportunità di iscriversi al programma USI-SUPSI sport, il quale, previo pagamento da parte dell’utente, viene convalidato apportando un tim-bro sul lato posteriore della tessera.
L’applicazione mira ad unire queste funzionalità già consolidate con l’utilizzo della tessera fisica in un punto centrale, l’applicazione, semplificando e promuovendo l’utilizzo delle offer-te.
Collegandosi tramite il login NetID fornito da SUPSI l’utente potrà mostrare direttamente la pagina principale dell’applicazione all’attività che promuove un’offerta per poterne immedia-tamente usufruirne.
L’autenticazione e la scelta della tipologia di carta da mostrare nell’applicazione vengono gestite da un backend, al quale avranno accesso gli amministratori della piattaforma, al suo interno sarà anche possibile modificare o aggiungere nuove offerte.
L’applicazione lato client è basata sui frameworks Ionic e Cordova, il quale permette di eseguire il software sia su smartphone Android che iOS senza avere sorgenti differenti. Il backend è sviluppato in JAVA utilizzando il framework Spring con un database MySQL.
L’applicazione è pensata per non permettere accessi contemporanei con più dispositivi da parte dello stesso utente. Per il login è stato utilizzato il sistema di login "Net-ID" di SUPSI nel quale vengono inserite le credenziali fornite dall’università. Il servizio di login, tramite
le API proprietarie, permette di avere alcuni dati riguardo l’utente che ha appena effettuato l’accesso, i quali verranno salvati nel database dell’applicazione, all’utente viene fornito un token JWT per le successive autenticazioni dallo stesso dispositivo, nel caso avvengano più login solo l’ultimo sarà valido, invalidando gli accessi effettuati da altri dispositivi, i quali dovranno quindi reimmettere le credenziali Net-ID nel sistema.
Questo permette di rendere la tessera MySUPSI utilizzabile ovunque mantenendo le pro-prietà di unicità, riducendo così al minimo la possibilità che le promozioni vengano utilizzate da più persone tramite un singolo account.
2.2
Compiti
Il sistema da sviluppare è composto da 3 parti:
• L’autenticazione, basata su “Net-ID”, per identificare l’utente e il suo ruolo all’interno della SUPSI (studente o collaboratore)
• L’applicazione mobile, sviluppata utilizzando framework cross-platform
• Un piccolo backend di gestione delle sessioni attive e delle offerte da visualizzare Obbiettivo del progetto è di intervenire su tutte e tre le parti, studiando e sviluppando una prima versione completa e funzionante del sistema.
Il partner di progetto, la direzione centrale della SUPSI, seguirà il design di interazione dell’app mobile e la parte grafica.
2.3
Tecnologie
Per l’autenticazione:
• Sistema “Net-ID” di TI-EDU
• JWT (Json Web Token) per gli accessi dopo la prima autenticazione
• Tecniche anti-cheating per evitare accessi multipli anche offline. Per l’applicazione mobile:
• Ionic e Cordova frameworks
• Angular 2
• HTML5
• CSS e SASS Per il backend:
• JAVA Spring framework
Introduzione alle tecnologie
3.1
Spring & Spring Boot
Spring è un framework open-source nato con l’intento di gestire la complessità nello sviluppo di applicazioni enterprise.
Grazie alla sua architettura estremamente modulare permette l’utilizzo parziale, anche in maniera incrementale, delle sue funzionalità.
Principalmente il framework permette di creare un servizio di API REST con gestione di sessioni e utenti in modo semplice e rapido, include anche un supporto di runtime embedded Apache Tomcat, il quale permette di eseguire l’applicazione senza bisogno di servizi esterni per esporre le API.
Spring è pensato per essere sviluppato seguendo le regole del pattern MVC.
Utilizzando le librerie JPA e Hibernate, Spring permette di interagire con database di diverso tipo (relazionali, noSql, grafi, ecc) senza esplicitare le query nel linguaggio noto al DBMS.
3.2
REST
REST, o REpresentational State Transfer, è un tipo di architettura software che fornisce standard tra i sistemi di computer sul Web, rendendo più semplice la comunicazione tra di essi.
Ai servizi che implementano il paradigma REST è lasciata piena libertà nello sviluppare le componenti del sistema, i quali devono però rispettare i seguenti vincoli:
• Client–server: l’implementazione del client e del server possono essere eseguite in
modo indipendente, senza che ciascuno conosca l’altro. Ciò significa che il codice sul lato client può essere modificato in qualsiasi momento, senza influire sul funzio-namento del server e viceversa. L’unica parte che lega i due sono i messaggi che devono scambiarsi, infatti il client deve sapere in che formato risponderà il server e saper trattare i dati ricevuti in modo adeguato.
• Stateless: i sistemi che implementano il paradigma REST sono privi di stato, il che
significa che il server e il client non hanno bisogno di sapere nulla sullo stato in cui si trova l’altro. In questo modo, entrambi possono comprendere qualsiasi messaggio ricevuto, senza informazioni riguardo eventuali messaggi precedenti.
• Cacheable: i client sono abilitati a fare caching delle risposte. In ogni caso, nelle
risposte, deve essere definito se sono o meno cacheable, in modo da evitare che i client possano utilizzare dati obsoleti o errati. Una gestione della cache potrebbe ridurre o parzialmente eliminare le comunicazioni client-server, migliorando di molto le performance dei servizi client.
• Layered system: Un client non può sapere se è connesso al server finale o ad altri
in-termedi, i quali possono garantire ulteriori livelli di sicurezza e permettono di migliorare la scalabilità con load-balancing o cache distribuite.
• Uniform Interface: Un’interfaccia uniforme tra client e server permette di avere
l’ar-chitettura semplificata e disaccoppiata, quindi libera di evolvere separatamente.
• Code on demand: i server sono in grado di estendere o personalizzare
temporanea-mente le funzionalità del client trasferendo del codice. Questo può includere com-ponenti compilati, ad esempio Applet Java o linguaggi di scripting come JavaScript. Questo è l’unico vincolo opzionale di un’architettura REST.
Questi vincoli consentono alle applicazioni RESTful di ottenere affidabilità, prestazioni ra-pide e scalabilità. I componenti che possono essere gestiti, aggiornati e riutilizzati senza influire sul sistema nel suo complesso, anche durante il funzionamento del sistema.
3.2.1
Richieste HTTP
Nell’architettura REST, i client, tramite il protocollo HTTP, inviano richieste per recuperare o modificare risorse e i server inviano risposte a tali richieste.
Per eseguire le richieste ci sono strutture standardizzate:
• Metodi HTTP: definiscono quale operazione stiamo effettuando • Header: permette al client di passare informazioni di base al server • Path: percorso per raggiungere la risorsa alla quale si vuole accedere
• Body: il corpo della richiesta, nel caso ci siano dei parametri specifici (opzionale)
3.2.1.1 Metodi HTTP
Lo standard definisce alcuni metodi HTTP che vengono utilizzati per interagire con il server, ognuno dei quali permette diverse operazioni:
• GET: recupera una risorsa specifica tramite id o una raccolta di risorse • PUT: aggiorna specifiche risorse identificate dall’id specificato nella richiesta
• POST: crea nuove risorse in base ai dati che il client invia al server nel body della
richiesta
• DELETE: cancella risorse specifiche identificate dall’id specificato nella richiesta • OPTIONS: si utilizza nel CORS, descritto nella prossima sezione, come specificato
, un meccanismo utilizzato dai client delle API per ottenere soltanto gli header di risposta, così da sapere, ad esempio, che tipo di dati il server accetta e quali ritorna, informazioni sul tipo di autenticazione necessaria per accedere, quali metodi HTTP il server accetta, ecc., questi dati servono ai client per poter formare correttamente le successive richieste
3.2.1.2 Header:
Nell’header della richiesta il client invia alcuni parametri utili al server, il loro scopo è specifi-care il tipo di client che ha effettuato la richiesta e quali risposte è in grado di elaborare, così da evitare di rispondere con contenuti non supportati dalla piattaforma o dall’applicazione. La sintassi è:Nome: <Valore>.
I campi in questione sono principalmente:
• Accept-Charset: specifica i charsets che il client riesce ad interpretare
• Accept-Encoding: specifica quali metodi di codifica il client è in grado di decodificare
• Accept-Language: specifica quali lingue il client accetta
Il client invia anche informazioni sull’utilizzo che fa della cache, molto utile nei browser per non dover effettuare il download di dati già ricevuti in passato, il campo presente nell’hea-der a tale scopo èCache-Control, nel quale è possibile specificare svariati parametri sia
riguardo la durata dei dati nella cache del client, sia riguardo ai tipi di dati che sono stati salvati.
All’interno dell’header è possibile inviare delle stringhe di autenticazione utilizzando il cam-poAuthorization, la sintassi per questo header è Authorization: <tipo> <credenziali>, ci
sono diversi tipi di autenticazione possibili:
• Basic: i campi username e password sono inviati al server nella forma
userna-me:password codificati in base64 hash, il protocollo https ne garantisce la sicurezza.
• Bearer: invia un token al server, il quale lo verifica e se valido, dà accesso alle risorse
protette. Il token è generato dal server al momento della prima autenticazione, quindi viene inviato al client, il quale dovrà salvarlo e includerlo nell’header delle richieste successive per autenticarsi. Il token è una stringa alfanumerica, potrebbe essere una stringa random che il server associa ad uno specifico utente, ma di norma è il risultato di una codifica di alcuni valori, un esempio è il token JWT, descritto nel capitolo successivo. Da specifiche la sicurezza è garantita solo dal protocollo https.
• Digest: è simile al metodo Basic, con la differenza che i campi username e password
non vengono codificati con un algoritmo reversibile ma crittografati con MD5, si ha quindi la possibilità di includerlo anche in richieste http e non soltanto in https. Inoltre le modalità di autenticazione sono più complesse, in quanto, non deve essere solo il client ad inviarlo, ma si deve instaurare un dialogo client-server prima di inviare la richiesta definitiva con l’header Authorization.
Nel caso dei browser gli header includono anche informazioni riguardo quale browser sta facendo la richiesta, a questo scopo viene utilizzato il campoUser-Agent, il server potrebbe
Un esempio di header presenti in una richiesta completa effettuata da un browser è la seguente:
a c c e p t : t e x t / html , a p p l i c a t i o n / x h t m l +xml , a p p l i c a t i o n / xml ; q = 0 . 9 , image / webp , image / apng ;
accept−encoding : g z i p , d e f l a t e , b r accept−language : i t−IT , i t ; q = 0 . 9 , en ; q =0.8 cache−c o n t r o l : no−cache pragma : no−cache user−agent : M o z i l l a / 5 . 0 ( L i n u x ; A n d r o i d 5 . 0 ; SM−G900P B u i l d / LRX21T ) AppleWebKit / 5 3 7 . 3 6 (KHTML, l i k e Gecko ) Chrome / 6 7 . 0 . 3 3 9 6 . 9 9 M o b i l e S a f a r i / 5 3 7 . 3 6 3.2.1.3 Path:
Le richieste sono formate dal metodo HTTP, descritto in precedenza, e da un percorso per raggiungere la risorsa necessaria.
Nel caso di un’API il risultato è formato soltanto da dati, solitamente in JSON o XML, questi dati formano le risorse che il servizio restituisce, mentre nel caso di un sito web, le risorse sono le pagine HTML, statiche o generate dinamicamente, che il server invia ai client nel momento della richiesta.
Generalmente è formato in modo gerarchico per essere comprensibile, ad esempio: www.mysite.com/customers/234/orders/32 indica che vogliamo raggiungere l’ordine con id 32 del cliente con id 234. I siti web non necessitano di documentazione, in quanto una volta raggiunta l’homepage del sito, la quale il più delle volte è la radice del sito stesso, è possibile, tramite link ipertestuali, raggiungere tutte le altre risorse.
Le API non avendo una parte navigabile, devono essere corredate di una documentazione che descrive i vari servizi, sia per come strutturare la richiesta, sia per mostrare come sarà il formato della risposta.
3.2.1.4 Body:
Il corpo della richiesta contiene i dati che il client vuole mandare al server, a differenza dell’header che contiene le informazioni riguardo la comunicazione client-server ed è quindi indispensabile, il body contiene informazioni riguardo i dati a cui accede il client e potrebbe anche non essere presente nelle richieste.
Viene utilizzato principalmente con i metodi PUT e POST, i quali devono mandare al server i dati delle entità che vogliono rispettivamente modificare o salvare, può essere comunque
inviato con ogni tipo di metodo HTTP, però nei casi di GET e OPTIONS è inutile, dato che questi metodi non dovrebbero mai richiedere al server di modificare i dati.
3.2.2
Risposte HTTP
Come conseguenza ad una richiesta, il server invia una risposta HTTP, la quale contiene i dati richiesti e altre informazioni, descritte all’interno dell’header di risposta.
3.2.2.1 Response Header:
L’header di risposta fornisce informazioni riguardo al server e parzialmente anche al conte-nuto della risposta.
I principali header presenti sono:
• HTTP/*: Versione del protocollo HTTP che si sta utilizzando
• Status Code: Un codice che descrive lo stato del server, i codici rispettano uno
standard e sono formati da 3 cifre, la prima indica il tipo di stato, e le altre 2 indicano informazioni più dettagliate:
– 1XX: Informazione – 2XX: Successo – 3XX: Redirezione – 4XX: Errore Client – 5XX: Errore Server
• Cache Control: Informa il client se e come è possibile salvare la risposta nella propria
cache.
• Content-Length: Specifica la lunghezza del corpo della risposta in byte • Content-Type: Specifica il tipo di dato presente nella risposta
• Last-Modified: Indica quando è stato modificata l’ultima volta la risorsa a cui si sta
accedendo, utilizzato per gestire la cache del browser
3.2.2.2 Body:
Il corpo della risposta contiene le risorse che il client ha richiesto, il tipo e la lunghezza dei dati all’interno sono definite dagli appositi header. Per una pagina web il contenuto del body è del testo html, mentre le API sono libere di tornare ogni tipo di dato, solitamente JSON o XML.
3.2.3
CORS
Il CORS (cross-origin HTTP request) avviene quando un client fa una richiesta ad un domi-nio differente dal proprio, ad esempio quando il server si trova su domidomi-nio X e il client su un altro dominio Y (oppure in un applicazione mobile), al momento della richiesta il server se non prevede che avvengano richieste da altri domini può generare degli errori.
Questi problemi non sono presenti nei casi in cui il server e il client siano sullo stesso domi-nio.
Per lo standard CORS ci sono 2 tipi di richieste:Simple Request e Preflight Request:
3.2.3.1 Simple Request
Una simple request permette soltanto alcuni metodi HTTP e Header:
• GET
• HEAD
• POST
I quali possono avere solamente questi header:
• Accept
• Accept-Language
• Content-Language: il quale a sua volta può contenere solo i seguenti valori: – application/x-www-form-urlencoded – multipart/form-data – text/plain • Content-Type • DPR • Downlink • Save-Data • Viewport-Width • Width
Se una richiesta soddisfa questi limiti e la risposta del server include l’headerAccess Con-trol allow origin specificando il dominio del client (o * che indica il permesso ad
accede-re da ogni dominio) allora il CORS non genera problemi e le richieste vengono effettuate normalmente indipendentemente dal dominio di client e server.
3.2.3.2 Preflight Request
Se una richiesta utilizza metodi o contiene header aggiuntivi allora viene identificata come preflight request, in questi casi il client deve prima inviare al server una richiesta con il metodo OPTIONS e il server deve validare la richiesta, ritornando una risposta con stato positivo (200 OK), una volta che il server ha validato la richiesta il client può inviare la richiesta vera e propria con successo. Lo schema seguente riassume una preflight request per una richiesta in POST contenente del codice XML (text/xml):
3.3
JWT
JSON Web Token (JWT) è uno standard aperto (RFC 7519) che definisce un modo com-patto, autonomo e sicuro per trasmettere le informazioni tra le parti come oggetto JSON. Questa informazione può essere verificata e ritenuta attendibile in quanto è firmata digital-mente. Le JWT possono essere firmate usando un segreto (con l’algoritmo HMAC) o una coppia di chiavi pubblica / privata usando RSA o ECDSA.
Sebbene le JWT possano essere crittografate per fornire anche segretezza tra le parti, la parte più importante sono i token firmati, i quali permettono di verificare l’integrità delle at-testazioni contenute al suo interno.
Nella loro forma compatta, i token Web JSON sono composti da tre parti separate da punti:
• Header: generalmente consiste di due parti: il tipo di token, che è JWT, e l’algoritmo
di hashing utilizzato, come HMAC, SHA256 o RSA. Ad esempio:
{
" alg ": " H S 2 5 6 " ,
" typ ": " JWT "
}
• Payload: contiene i claims. I claims sono dichiarazioni relative a un’entità (in genere,
l’utente) e dati aggiuntivi. Esistono tre tipi di claims:
– Claims registrati: si tratta di una serie di claims predefiniti che non sono
ob-bligatori ma raccomandati per fornire alcune informazioni utili e interoperabili. Esempi di claims sono: iss (emittente), exp (scadenza), sub (oggetto) e altri.
– Claims pubblici: questi possono essere definiti a piacimento da coloro che
usano i JWT, ma per evitare collisioni dovrebbero essere definite nel Registro dei token Web JSON di IANA.1
– Claims privati: sono richieste personalizzate create per condividere le
infor-mazioni tra le parti, le quali concordano sul loro utilizzo e non sono né claim registrati né pubblici.
Un esempio di payload può essere:
{
" sub ": " 1 2 3 4 5 6 7 8 9 0 " ,
" name ": " John Doe " ,
" a d m i n ": true }
1
• Signature: Per creare la parte della firma bisogna prendere l’intestazione codificata, il
payload codificato, un segreto e l’algoritmo specificato nell’intestazione, infine firmare l’intero JWT.
Ad esempio, se si desidera utilizzare l’algoritmo HMAC SHA256, la firma verrà creata nel modo seguente:
H M A C S H A2 5 6(
base6 4U r l E n c o d e ( h e a d e r ) + " . " + base6 4U r l E n c o d e ( p a y l o a d ) ,
s e c r e t )
L’output è costituito da tre stringhe Base64-URL separate da punti che possono essere facilmente passate negli ambienti HTML e HTTP.
Quanto segue mostra una JWT con l’intestazione precedente, il payload codificato, ed è firmata con un segreto:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ zdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4 gRG9lIiwiYWRtaW4iOnRydWV9.8ayznaGGRy4Z8w Qg8KC7IzRWY86bZRAAuCuVOXsXYfw
3.4
Ionic e Cordova
Ionic Framework è un SDK open source che consente di creare app mobili ibride perfor-manti e di alta qualità utilizzando tecnologie web familiari (HTML, CSS e JavaScript). Ionic si concentra principalmente sull’aspetto e sull’interfaccia utente di un’app. Il framework utilizza AngularJS e si basa su Apache Cordova per la parte nativa.
L’applicazione mobile è sviluppata con tecnologie Web, ma viene eseguita localmente al-l’interno di un’applicazione nativa e può interagire con le funzionalità del dispositivo appog-giandosi all’infrastruttura di Apache Cordova il quale mette a disposizione una WebView nella quale esegue il codice di Ionic.
Figura 2: Ionic-cordova
3.4.1
Nativo vs Ibrido
Nell’ambito dei software per dispositivi mobili si possono trovare 3 categorie:
• Applicazioni native: sono applicazioni create per poter funzionare su un solo
si-stema operativo e sono scritte con il linguaggio di programmazione specifico per la piattaforma, le piattaforme più diffuse, Android e iOS hanno come base due linguag-gi differenti, rispettivamente Java e Objective-C. Per essere utilizzate devono essere installate sul dispositivo.
• Web Application: sono applicazioni accessibili tramite il browser dello smartphone,
quindi non richiedono un’installazione ma sono interamente mostrate come fosse un sito web.
• Applicazioni ibride: sono applicazioni scritte in un linguaggio comune a tutte le
piat-taforme, solitamente javascript e HTML 5, vengono compilate come una web app e incapsulate nel browser che le esegue, non risiederanno quindi sul server come que-ste ultime, ma per utilizzarle bisogna installare l’applicazione che comprende sia il codice eseguibile sia la webView nella quale viene mostrata.
3.4.1.1 Vantaggi e Svantaggi
Le applicazioni native hanno il vantaggio di potersi interfacciare completamente con il di-spositivo e di conseguenza hanno accesso a tutte le componenti hardware e software che il produttore mette a disposizione, lo svantaggio si presenta nel momento in cui si vuole svi-luppare un’applicazione multi-piattaforma, in quanto si dovranno svisvi-luppare più applicazioni completamente differenti tra loro. In conclusione le applicazioni native sono più performanti e complete ma richiedono più tempo e conoscenze per essere sviluppate.
Le applicazioni ibride hanno il vantaggio di avere il codice uguale per ogni piattaforma quin-di trovano posto nei casi quin-di applicazioni multi-piattaforma semplici, infatti a quin-differenza delle app native hanno accesso solo ad una parte delle funzionalità del hardware e software del dispositivo rendendole di fatto meno performanti. Concludendo queste sono ottime nel ca-so di applicazioni semplici e multi-piattaforma quando non si rende necessario l’accesca-so ai sensori di vario tipo presenti nei dispositivi.
3.5
Docker
Docker è uno strumento open source progettato per semplificare la creazione, l’implemen-tazione e l’esecuzione delle applicazioni utilizzando i containers.
I containers consentono a uno sviluppatore di impacchettare un’applicazione con tutte le parti di cui ha bisogno, come librerie e altre dipendenze, e spedirla in un unico pacchetto. In questo modo, grazie al container, lo sviluppatore può essere certo che l’applicazione verrà eseguita su qualsiasi altra macchina Linux, indipendentemente dalle impostazioni perso-nalizzate della macchina che potrebbero differire dalla macchina utilizzata per scrivere e testare il codice.
In un certo senso, Docker è simile ad una macchina virtuale. Ma a differenza di questa, an-ziché creare un intero sistema operativo virtuale, consente alle applicazioni di utilizzare lo stesso kernel Linux del sistema su cui sono in esecuzione e richiede solo che le applicazio-ni vengano condivise con elementi che non sono già in esecuzione sul computer host. Ciò consente un notevole incremento delle prestazioni e riduce le dimensioni dell’applicazione. Docker è uno strumento progettato per avvantaggiare sia gli sviluppatori che gli amministra-tori di sistema.
Per gli sviluppatori, significa che possono concentrarsi sulla scrittura del codice senza do-versi preoccupare del sistema su cui alla fine verrà eseguito. Consente inoltre di ottenere un vantaggio utilizzando uno dei migliaia di programmi già progettati per essere eseguiti in un contenitore Docker come parte della loro applicazione.
Per il personale operativo, Docker offre flessibilità e potenzialmente riduce il numero di sistemi necessari grazie del suo ingombro ridotto.
Progetto
Il progetto prevede lo sviluppo di un’applicazione mobile ibrida e di una lato server che ser-virà i contenuti alla prima con un backend a cui poter accedere per inserire e modificare dati riugardanti utenti e offerte.
L’utente che intende utilizzare l’applicazione, una volta installata, dovrà accedere con il login NET-ID fornito dall’università. L’applicazione al primo avvio richiede all’utente di scattar-si una foto, la quale verrà inviata al server e convalidata dai responsabili SUPSI, i quali tramite il backend avranno accesso ai dati dell’utente e visioneranno quindi la foto. Una volta accettata, la foto comparirà nella homepage dell’applicazione e l’utente potrà utilizzare l’applicazione liberamente.
Per quanto riguarda il permesso USI/SUPSI sport, gli utenti dovranno, come già accade attualmente, pagare tramite il bollettino messo a disposizione da SUPSI la quota di iscri-zione. I responsabili per lo sport SUPSI, una volta ricevuto il pagamento provvederanno, tramite il backend, ad abilitare la promozione, la quale risulterà da quel momento visibile sull’applicazione e quindi utilizzabile dall’utente.
4.1
Server
Il server, sviluppato in Java con il framework Spring Boot, lavora con un database MySQL, nel quale vengono salvati i dati degli utenti.
Il compito del server è gestire la logica del sistema, fornire API REST per l’applicazione, popolare, modificare il database, gestire gli accessi degli utenti e infine fornire un backend tramite cui gli operatori possano gestire utenti e benefit.
4.1.1
Database
Il database é associato al server tramite JPA (Java Persistence API), strumento di Spring che permette di interagire con qualunque tipo di DB con le classiche operazioni CRUD(Create-Read-Update-Delete), questo permette di non doversi preoccupare del tipo e della versione del database durante lo sviluppo, il framework infatti, basandosi su un file di configurazione, si occupa di tradurre il codice, facendo da intermediario tra il software e il DBMS.
Il DBMS che è stato utilizzato è di tipo relazionale, precisamente MySQL. Il diagramma ER (Entity-Relationship) del database è il seguente:
Figura 3: Database ER schema
Le immagini persistite nel database sono tutte codificate in Base64 per semplicità di utilizzo.
4.1.2
Accessi
Per il login è stata utilizzata l’API sCAS di Switch assieme ad un token JWT.
4.1.2.1 Login NET-ID
Il servizio NET-ID di TI-EDU, basato su sCAS di Switch, espone un’API grazie alla quale è possibile collegare un servizio esterno e ricevere come risposta i dati dell’utente che ha effettuato il login in risposta, un esempio é:
https://login2.supsi.ch/sCAS/login?service=https://www.my-service.com/
Quando si effettua una chiamata in GET a questo URI, si accede alla pagina di login Switch, una volta immesse le credenziali corrette, il browser verrà rediretto all’URI inserito nella ri-chiesta come parametro service includendo un ulteriore parametro ticket:
https://www.my-service.com/?ticket=*** , quando questa richiesta viene elaborata dal
ser-ver, esso dovrà ritornare il ticket all’API di SWITCH insieme al servizio per il quale il ticket è stato generato per convalidarlo, tramite l’URI:
https://login2.supsi.ch/sCAS/serviceValidate?ticket=***&service=... come risposta si riceve-ranno i dati di base dell’utente che ha effettuato il login.
Qui riportato un esempio di riposta dell’API di TI-EDU: <cas:serviceResponse>
<cas:a u t h e n t i c a t i o n S u c c e s s>
<cas:user>nome . cognome@netid< /cas:user> <cas:a t t r i b u t e s>
<cas:u i d>nome . cognome@netid< /cas:u i d>
<cas:m a i l>nome . cognome@ . s u p s i . ch< /cas:m a i l> <cas:e d u P e r s o n A f f i l i a t i o n>
[ s t a f f , s t u d e n t ]
< /cas:e d u P e r s o n A f f i l i a t i o n> <cas:cn>Nome Cognome< /cas:cn> < /cas:a t t r i b u t e s>
< /cas:a u t h e n t i c a t i o n S u c c e s s> < /cas:serviceResponse>
Come si può notare dall’esempio precedente, potrebbero presentarsi dei casi in cui un uten-te risulti sia collaboratore (staff) sia studenuten-te (student), in questi casi è stato deciso assieme alla direzione che il ruolo con la priorità è quello di studente, poiché tutte le offerte riservate ai collaboratori sono anche riservate agli studenti, ma non viceversa.
4.1.2.2 Long-polling
Visto il funzionamento del sistema di login sCAS descritto in precedenza, deve essere il server ad occuparsi di gestire le comunicazioni con TI-EDU, le quali però sono generate dal client e di conseguenza è stato implementato un sistema di long-polling.
Con long-polling si riassume il meccanismo di effettuare una chiamata ad un URI che ri-sponderà solamente quando avrà un risultato valido, in caso di timeout, chi ha effettuato la chiamata deve occuparsi di ripeterla, questo si deve ripetere fino a che si riceve una rispo-sta, diversa da "408 Timeout connection", dal server.
Nel server l’implementazione segue questa logica:
Una volta ricevuta una richiesta di long-polling2, il server prepara una risposta per il client e la inserisce in una mappa, identificata dal parametro ID presente nella richiesta.
Il completamento della richiesta avviene quando il server riceve una chiamata all’URI3 che rappresenta il login avvenuto, questo deve contenere lo stesso ID utilizzato per avviare il long-polling e il parametro "ticket", il cui scopo è descritto nel capitolo precedente.
A questo punto il server invia il ticket ricevuto al servizio sCAS, il quale ritorna i dati dell’u-tente che ha effettuato il login, vengono quindi analizzati i dati ricevuti e viene generato un token JWT unico per l’utente.
Il token viene incluso nella risposta, quindi la comunicazione long-polling si chiude.
Di seguito un flowchart che descrive il sistema di long-polling.
Figura 4: Login Server Side FlowChart
2Vedi sezione Endpoints @api/loginRequest 3
4.1.3
Endpoint REST
Tutti gli endpoint REST rispondono con oggetti Json. In caso di errore la risposta sara del tipo:
{type: error, reason: reason, details: details }
Gli endpoint REST che il server mette a disposizione sono i seguenti:
Senza token nell’header: • GET /api/loginRequest?id
– PARAM id: identificativo client che effettua richiesta
RETURN: richiesta asincrona (long-polling) ritorna il token una volta effettuato il login.
{type: token, token: token }
• GET /api/loginSuccess?id&ticket
– PARAM id: identificativo client che ha effettuato la richiesta /api/loginRequest – PARAM ticket: ticket fornito da sCAS a login effettuato
RETURN: permette il ritorno della richiesta /api/loginRequest, chiamata
singolarmen-te non ritorna nulla
Token necessario nell’header (in caso contrario 401 unauthorized): • GET /api/request/checkUserPermission
RETURN: endpoint di supporto, utilizzato per verificare validità token
{type: info, info: "access permitted"}
• GET /api/request/ServerTime
RETURN: ritorna l’ora del server in formato Epoch
{type: data, data: value }
• GET /api/request/userData
RETURN: ritorna tutti i dati dell’utente
{type: data, data: {user }}
• POST /api/request/userDataUpdate – BODY user: utente con dati aggiornati RETURN: ritorna tutti i dati dell’utente aggiornati
• GET /api/request/benefits
RETURN: ritorna tutte le categorie delle offerte senza le immagini (lazy loading)
{type: data, data: [{benefitCategory }]}
• GET /api/request/fullBenefitCategory/{id} – PATH VARIABLE id: id categoria
RETURN: ritorna la categoria completa di tutti gli attributi
{type: data, data: {benefitCategory }}
• GET /api/request/benefits/{id} – PATH VARIABLE id: id categoria
RETURN: ritorna tutte le offerte della categoria senza immagini (solo quelle riservate
al ruolo dell’utente, l’utente viene estratto dal token)
{type: data, data: [{benefit }]}
• GET /api/request/benefit/{id} – PATH VARIABLE id: id benefit
RETURN: ritorna l’offerta completa di tutti gli attributi
4.1.4
Struttura classi
Le API REST descritte precedentemente spesso ritornano oggetti JAVA mappati in JSON, per questo è importante conoscere la struttura delle classi e il nome di ogni campo presente negli oggetti che il client riceve.
La struttura delle classi che riguarda l’utente è la seguente:
Figura 5: Diagramma classi utente
I campi che necessitano di spiegazioni dettagliate sono:
• customDataPresent: flag di supporto per evitare di accedere a il campo
mySupsiU-serCustomData non inizializzato, infatti quando l’oggeto user viene mappato come JSON non è più possibile sapere se vi sono o meno dati presenti.
• sportExpiration: campo che contiene lo stesso valore di sportExpirationDate in
mil-lisecondi, inserito per risolvere incompatibilità tra il tipo di dato Date quando viene mappato in JSON.
• refuseMotivation: questo campo viene riempito sono se la foto che l’utente inserisce
non rispetta gli standard previsti, è utilizzato in combinazione con customDataPresent e validated.
• role: il ruolo è una struttura usata internamente da Spring per l’autenticazione degli
utenti.
• MySupsiRole.TUTTI: utilizzato nei benefit, assegnato ad un benefit valido sia per
collaboratori (STAFF) sia per studenti (STUDENT). La struttura delle classi che riguarda le offerte è:
Figura 6: Diagramma classi benefit
I campi che necessitano di spiegazioni dettagliate sono:
• image: a differenza degli utenti, dove l’immagine viene codificata già
nell’applicazio-ne, il logo delle offerte viene caricato tramite un form, il dato che arriva dal form al backend è di tipo MultipartFile, questo valore non viene salvato nel database, ma non appena ricevuto viene convertito in Base64 salvato nel campo imageBase64.
4.1.5
Interfaccia Backend
L’interfaccia per il backend è integrata in Spring, in parte è stato sviluppata utilizzando il template-engine Thymeleaf, il quale permette di mappare gli oggetti Java direttamente nelle pagine HTML, limitando al minimo l’utilizzo di Javascript per ottenere/inviare dati.
Per l’interfaccia grafica è stato utilizzato il framework responsive Bootstrap V4.1
Tutte le pagine, tranne quella di login, contengono head, header e footer comune, trami-te i link della navbar nell’header è possibile spostarsi tra le pagine.
Le pagine sviluppate nel backend sono:
• login: semplice interfaccia di login
• homepage: home vuota, grafica da definire
• users: contiene 3 tabelle, la prima per gli utenti da convalidare, la seconda che
raggruppa quelli già convalidati e la terza contenente gli utenti la cui foto è stata rifiutata.
• user_form: mostra i dati dell’utente.
• benefits: mostra le categorie delle offerte e il tasto per aggiungerne di nuove, per
ogni categoria è presente il tasto modifica e elimina.
• benefit_detail: mostra, in una tabella, le offerte di una specifica categoria. • benefit_form: permette la creazione o la modifica di un’offerta.
• benefit_category_form: permette la creazione o la modifica di una categoria di
offerte.
• fragments: contiene parti di codice che vengono richiamate in altre pagine. • header/footer/head: contengono le parti comuni a tutte le pagine
Tutte le tabelle presenti nell’interfaccia sono state create utilizzando la libreria DataTa-bles.js4, che permette la paginatura delle tabelle, in modo da evitare di passare grosse moli di dati alle pagine.
4
4.2
Client
Il client è un’applicazione mobile ibrida, sviluppata con il framework Ionic.
Grazie a Ionic, l’applicazione è multi-piattaforma, può infatti essere eseguita sia su Android sia su iOS. Comunica con il server tramite le API REST descritte in precedenza che que-st’ultimo mette a disposizione.
La parte grafica è stata implementata basandosi sulle linee guida date dalla direzione SUP-SI, mentre la parte logica è stata sviluppata autonomamente, la direzione ha comunicato solamente quali erano i requisiti che l’applicazione avrebbe dovuto soddisfare.
4.2.1
Grafica
L’applicazione è divisa in 2 parti principali, raggiungibili da un menù sempre visibile sul lato inferiore:
Figura 7: Menù tab applicazione
La parte principale, mySUPSI contiene i dati dell’utente, è visualizzata all’avvio dell’applica-zione e si presenta cosi:
Figura 8: Home page applicazione
In essa sono visibili dall’alto al basso:
• Data termine sport: visibile solo se la promozione USI/SUPSI sport è stata attivata,
questa sezione mostra la data nella quale termina l’offerta.
• Foto utente: Nella parte centrale è presente la foto dell’utente che ha effettuato il
login.
• Scritta scorrevole: Una scritta in continuo movimento da sinistra a destra, che
mo-stra il contenuto completo dell’acronimo SUPSI nelle 4 lingue nazionali.
• Dati Utente: Nome e cognome dell’utente con tasto di logout.
• Ruolo + eventuale Matricola: Ruolo dell’utente loggato (Studente o Collaboratore),
nel caso di studenti è previsto anche il numero di matricola.
La seconda parte mostra le offerte disponibili, la prima pagina che si raggiunge contiene le categorie dei benefit, cliccando su una di esse si accede ad una nuova view contenente la lista dei benefit per la categoria selezionata, infine cliccando sulla singola offerta si ottiene la pagina di dettaglio dell’offerta con tutte le informazioni riguardo l’offerta selezionata. N.B: I testi e le foto all’interno dell’immagine seguente sono generati casualmente (lorem ipsum), l’applicazione reale mostra i dati caricati nel backend:
4.3
Funzionamento applicazione
Il caricamento dell’applicazione può essere descritto dal seguente diagramma di flusso:
Figura 10: Diagramma di flusso applicazione completa
Le parti di verifica del token vengono trattate in dettaglio nella sezione Autenticazione client del capitolo Sicurezza.
Come si può vedere il caricamento dei dati avviene soltanto ad autenticazione effettuata, dopo di che si passa al controllo dei dati, verificando sia la presenza della foto, sia se la foto è stata convalidata, infine viene verificato se l’utente ha sottoscritto l’abbonamento USI/-SUPSI sport.
Le fasi descritte nel diagramma precedente si presentano così durante l’esecuzione del-l’applicazione:
• Login: Se il token nel dispositivo non è presente, è scaduto o non è valido l’ap-plicazione dopo aver terminato il caricamento e la verifica mostra la pagina di login NET-ID:
Figura 11: Applicazione - login
• Nessuna foto: Se l’utente non ha ancora scattato la sua foto profilo, essa viene
richiesta, alla pressione del tasto "OK" si apre automaticamente la camera frontale, una volta scattata la foto viene richiesto di ritagliarla correttamente, infine la foto è caricata sul server, compare un messaggio di informazioni e l’app resta in attesa che la foto venga convalidata.
• Foto non accettata: Nel caso in cui la foto venga rifiutata dalla direzione, appare un
messaggio che ne notifica il rifiuto, con la motivazione inserita.
Alla pressione del tasto "OK" viene aperta la fotocamera frontale per scattare la foto, da questo punto il procedimento è uguale al precedente punto.
Figura 13: Applicazione - foto rifiutata
• Caricamento completo: Una volta caricata la foto e convalidata nel server
l’applica-zione si avvia completamente mostrando i dati dell’utente, se questo ha anche sotto-scritto l’abbonamento sport, l’applicazione si presenterà come l’ultima delle prossime immagini, altrimenti sarà come nella penultima.
4.4
Sicurezza
La parte su cui il progetto si focalizza è la sicurezza, dove sono stati messi in pratica alcu-ni accorgimenti per assicurarsi il funzionamento sicuro dell’applicazione, anche quando lo smartphone si trova senza connessione.
4.4.1
Autenticazione server
Una volta ottenuti i dati da NET-ID il server provvede a generare un token JWT firmato con-tenente parte dei dati dell’utente della durata di 30 giorni, dopo i quali il token sarà invalidato. Il token generato oltre ad essere ritornato al client, viene anche persistito nel database, in modo da poterlo confrontare e verificare negli accessi futuri dell’utente, evitando così di do-ver chiedere nuovamente le credenziali di accesso.
Tutti gli endpoint che che iniziano con api/request/ necessitano di autenticazione
trami-te JWT, il token deve essere messo nell’header della richiesta come Authorization.
Se la richiesta viene fatta senza un token valido viene generata una risposta di errore con stato 401 (unauthorized).
Di seguito il diagramma di flusso di come il server verifica il token:
4.4.2
Unicità accesso
Un requisito fondamentale del progetto è rendere unico l’accesso di ogni utente, ovvero evitare che un dato utente possa connettersi da più dispositivi contemporaneamente, questo viene gestito grazie al token JWT che è generato all’accesso e si lega al dispositivo dal quale è stato effettuato il login, se l’utente prova ad accedere da un nuovo dispositivo, il vecchio token presente nel database viene sovrascritto dal nuovo, di conseguenza quando vorrà accedere nuovamente con il primo dispositivo il server non riconoscerà il token ricevuto, ritornando così il codice di errore di mancata autorizzazione.
4.4.3
Autenticazione client
In questo diagramma di flusso viene descritta la fase di autenticazione del client con le possibili risposte del server alle varie chiamate.
Figura 16: Flow Chart autenticazione lato client
Le parti fondamentali sono essenzialmente 3:
• Recupero e verifica token: Appena avviata l’applicazione il client verifica la presenza
fase di login, se invece il token è stato salvato in memoria in un accesso precedente l’applicazione prova ad effettuare una chiamata al server includendo il token nell’hea-der della richiesta, se il token non è valido viene chiesto un nuovo login, altrimenti la chiamata termina con successo e si procede infine a recuperare i dati dell’utente dal server, i quali, una volta ottenuti, vengono persistiti nella memoria locale.
• Login: Se il token non è presente, è scaduto, è stato modificato o non è più valido
viene lanciata la procedura di login.
All’avvio la connessione long-polling5 viene aperta e resta in attesa di una risposta. Successivamente si visualizza la pagina di login NET-ID in un browser integrato e la pagina resta visibile fino a che non si forniscono delle credenziali valide.
Una volta effettuato correttamente il login NET-ID, si ottiene un nuovo token come risposta alla connessione in long-polling, il token viene quindi salvato sovrascrivendo il precedente.
L’applicazione a questo punto passa alla fase di verifica del token descritta sopra.
• Server non raggiungibile: nel caso in cui il server non sia raggiungibile, a causa
un malfunzionamento del server stesso, o perché il dispositivo si trova senza una connessione di rete, l’applicazione provvede a verificare quanto tempo prima è stato effettuato l’ultimo accesso al server, se esso è avvenuto entro 24 ore, il client carica i dati salvati in precedenza in memoria, rendendo quindi l’applicazione funzionante anche offline.
5
4.4.4
Anti-cheating
Altro punto fondamentale trattato nel progetto riguarda l’anti-cheating, si tratta di implemen-tare funzionalità con lo scopo di prevenire comportamenti da parte degli utenti che possono portare ad un uso fraudolento dell’applicazione.
Oltre alle verifiche riguardanti l’autenticazione descritte in precedenza, sono stati implemen-tati alcuni accorgimenti per evitare che utenti non autorizzati o terzi utilizzino l’applicazione senza averne i diritti.
4.4.4.1 Offline
Il progetto prevede che l’applicazione funzioni anche offline per un tempo prestabilito di 24 ore dall’ultimo accesso al server, questo requisito crea alcune problematiche legate al poter verificare i dati senza una connessione al server, di seguito vengono elencati i problemi che sono stati trattati:
• Verifica ora offline: L’unico modo per conoscere l’ora attuale senza una connessione
è prenderla dal telefono stesso, questa però è modificabile dall’utente, che potrebbe modificarla fino a rendere validi i dati anche dopo il tempo fissato di limite.
SOLUZIONE POSSIBILE: (non implementata) si potrebbe tenere traccia di ogni
ac-cesso offline dell’utente, in modo di ridurre, man mano che l’utente effettua accessi, la finestra di tempo in cui è possibile accedere senza una connessione al server. Se venisse rilevato un accesso precedente all’ultimo, l’applicazione si metterebbe in stato di errore richiedendo nuovamente il login.
• Accesso sport: La parte dello sport è quella più delicata, infatti è l’unico servizio
offerto dall’applicazione che prevede un pagamento.
Il dato che viene inserito dagli operatori SUPSI all’interno del profilo utente per valida-re lo sport è la data fino a cui l’utente può usufruivalida-re dei vantaggi di USI SUPSI sport, l’applicazione dovrebbe quindi fare un confronto tra la data di scadenza presente nel profilo utente e la data attuale, i problemi che si presentano sono gli stessi che si han-no per la verifica dell’ora offline, la data del dispositivo è modificabile dall’utente.
SOLUZIONE: (implementata) la verifica del permesso sport non viene effettuata
offli-ne, quando il dispositivo è offline l’applicazione non mostra nulla riguardo lo sport. La data viene infatti richiesta al server e non presa dal dispositivo.
4.4.4.2 Autenticità applicazione
Per utilizzare un’offerta, l’utente deve mostrare l’applicazione all’esercente, il quale deve po-tersi assicurare che non stia guardando uno screenshot o un video dell’app.
Per questi motivi sono state implementate 2 soluzioni, la prima inserendo un elemento ani-mato, la seconda rendendo l’applicazione interattiva, cioè che reagisce a determinati input.
Figura 17: Testo animato
L’interattività è ottenuta facendo muovere in altro e in basso la scritta toccando sulla foto dell’utente:
Conclusioni
Il progetto è stato completato e dispone di tutte le caratteristiche richieste. Tutto il software è stato sviluppato in modo da poter essere esteso qualora vi sia la necessità. Gli incontri settimanali con il committente hanno permesso di chiarire molti dettagli riguardo l’attuale funzionamento del sistema di gestione delle tessere MySupsi, rendendo di fatto il progetto un valido sostituto. L’applicazione mobile è provvista di controlli anti-cheating per evitare che venga manipolata, sarà compito dell’esercente al quale l’utente mostra l’app verificare che si tratti dell’applicazione autentica.
Una volta avviata l’applicazione e fatto il login viene richiesto all’utente di scattarsi una fo-to, la quale sarà successivamente validata da un collaboratore designato della direzione centrale SUPSI, con la foto validata l’utilizzatore sarà in grado di mostrare l’applicazione al posto della tessera MySupsi per identificarsi come studente o collaboratore SUPSI.
5.1
Sviluppi futuri
Le potenzialità dell’applicazione sono molte, sviluppi futuri potrebbero includere:
• Profilo Studente: fornire informazioni sui corsi seguiti.
• Statistica: tramite un QR code specifico per ogni offerente di benefit si potrebbe
valutare l’utilizzo reale di ogni offerta.
• Traduzione: implementazione di lingue differenti sull’applicazione
• Mail: per ogni operazione effettuata sul profilo utente, inviare una mail informandolo
delle modifiche
• Modificare interfaccia backend: L’interfaccia di backend è stata sviluppata solo per
