Gestionale per la formazione basato su blockchain

Studente/i

Zyril Errol Gatchalian

Relatore

Amos Brocco

Correlatore

-Committente

Amos Brocco

Corso di laurea

Ingegneria Informatica

Modulo

Progetto di laurea

Anno

2019

Data

Indice

1 Abstract 1 2 Obiettivi 3 3 Tiforma 5 3.0.1 Elementi principali . . . 6 3.0.1.1 Contatto . . . 6 3.0.1.2 Formazione . . . 6 4 Tecnologie utilizzate 7 4.1 Blockchain . . . 7 4.2 Hyperledger . . . 8 4.2.1 Hyperledger Fabric . . . 8 4.2.2 Hyperledger Composer . . . 9 4.3 Angular 7 . . . 10 4.4 NodeJS . . . 10 5 Struttura preesistente 11 5.1 Funzionalità . . . 11 5.2 Back-end . . . 12 5.2.1 Participants . . . 12 5.2.2 Assets . . . 13 5.2.3 Transactions . . . 14 5.3 Front-end . . . 15 5.4 Queries . . . 15 5.4.1 Problematiche . . . 16 5.4.2 Soluzione . . . 16 5.5 Struttura generale . . . 16 6 Nuova Struttura 17 6.1 Middleware . . . 17 6.2 Divisione in moduli . . . 18

ii INDICE

6.3 Autenticazione . . . 19

6.4 Gestione Utenti . . . 23

6.5 Funzionalità di ricerca ottimizzata . . . 25

6.6 Reporting . . . 26

6.7 Allegati . . . 29

6.8 Miglioramento dell’interfaccia web . . . 29

7 Test 31 8 Pianificazione e gestione 33 9 Sviluppi futuri 35 9.1 Recupero Password . . . 35

9.2 Controllo sui campi . . . 35

10 Conclusioni 37 11 Manuale d’installazione 41 11.1 Installazione Hyperledger . . . 41

11.2 Installazione Middleware . . . 42

11.3 Installazione Front-end . . . 42

12 Manuale di attivazione del sistema 43 13 Manuale d’uso 45 13.1 Login . . . 45 13.2 Menù . . . 45 13.3 Studenti . . . 46 13.4 Dipartimenti . . . 46 13.5 Corsi . . . 46 13.6 Moduli . . . 46 13.7 Formazione . . . 46 13.8 Semestre . . . 46 13.9 Certificazione . . . 46 13.10Ricerca . . . 47

Elenco delle figure

3.1 TIFORMA Windows Version . . . 5

4.1 Esempio Blockchain . . . 7

4.2 Esempio Blockchain invalidata . . . 8

4.3 Soluzione Hyperledger . . . 9

4.4 Struttura Hyperledger Composer . . . 9

5.1 Student . . . 12

5.2 Certification . . . 14

5.3 Funzionamento struttura hyperledger-angular . . . 16

6.1 Funzionamento struttura hyperledger-middleware-angular . . . 17

6.2 Struttura in moduli del middleware . . . 19

6.3 Form di Login . . . 21

6.4 Form di registrazione . . . 21

6.5 Funzione authorize() . . . 22

6.6 Oggetto salvato nel log delle operazioni . . . 23

6.7 Funzione printOperation() . . . 23

6.8 Funzioni di delete e get degli users . . . 24

6.9 Navbar con Gestione Utenti . . . 25

6.10 Form per la gestione Utenti . . . 25

6.11 Mappatura query nel server . . . 26

6.12 Esempio query: ricerca dello studente per nome . . . 26

6.13 Funzione di stampa dello studente . . . 27

6.14 Form student-detail . . . 28

6.15 Dialog di stampa . . . 28

6.16 Form student-detail con eliminazione allegato . . . 29

6.17 Form student-detail con aggiunta di allegati . . . 29

6.18 Interfaccia Tiforma . . . 30

iv ELENCO DELLE FIGURE

7.1 Procedura che crea uno studente tramite curl . . . 31

7.2 Test createStudent() . . . 32

7.3 Esempio test output . . . 32

Capitolo 1

Abstract

I percorsi formativi degli studenti sono attualmente gestiti tramite un applicativo software chiamato TIFORMA, sviluppato, allo stato attuale, per soddisfare i requisiti della SUPSI (Scuola Universitaria Professionale della Svizzera Italiana). Il software in questione è un programma installato su sistema operativo Windows e permette di gestire la fase di prei-scrizione e iprei-scrizione degli studenti a dei piani di studio contenenti moduli singoli o modelli, l’iscrizione effettiva degli studenti ai moduli e la creazione di sessioni di certificazione nella quale gli utenti che effettueranno gli esami si vedranno assegnare una nota.

La soluzione qui sopra descritta si basa su un database centralizzato. Il problema prin-cipale è che è difficile verificare chi ha fatto cosa non avendo la possibilità di consultare uno storico delle aggiunte/modifiche/eliminazioni effettuate dagli utenti autorizzati ad accedere alla piattaforma. Tali utenti si devono quindi fidare dello stato del database centralizzato senza la possibilità di verificarne la consistenza dei dati.

L’obiettivo di questo progetto di laurea è quello di implementare una soluzione basata su blockchain al problema della gestione dei percorsi formativi. Quindi creare sia una struttura back-end (modellizzazione dei dati, generazione di un web server con metodi CRUD) e una front-end, offrendo un prototipo con delle funzionalità di base basate sulla versione attual-mente utilizzata.

Attraverso la tecnologia blockchain si vuole creare una soluzione in cui i dati siano distri-buiti/replicati e verificabili da chiunque disponga di una copia della blockchain stessa.

Capitolo 2

Obiettivi

Gli obiettivi di questo progetto sono:

– Implementazione della gestione dei profili utente e gestione della loro autenticazione e permessi

– Ottimizzazione delle funzionalità di ricerca – Implementazione della funzionalità di reporting

– Completamento delle informazioni riguardanti le persone e formazione – Implementazione della funzionalità di aggiunta di allegati e foto

Capitolo 3

Tiforma

L’applicazione attualmente utilizzata nella sede SUPSI per gestire il percorso formativo degli studenti è sviluppata come applicazione Windows e permette una moltitudine di operazioni. Come mostrato in Figura 1, tutte le funzionalità sono gestite tramite un menù laterale (rosso) che permette di accedere alle varie pagine dell’applicazione. Una volta effettuato l’accesso al menu, la barra in alto si modifica in base alla voce scelta (contestuale).

6 Tiforma

3.0.1

Elementi principali

Gli elementi principali che compongono questa applicazione sono diversi e ben distinti nel menu verticale sulla sinistra.

3.0.1.1 Contatto

È la gestione di tutte le informazioni dei contatti (studenti, collaboratori). In queste pagine possiamo inserire tutte quelle informazioni per registrare una persona al sistema.

3.0.1.2 Formazione

In questa area si organizzano tutte le informazioni riguardanti il percorso formativo vero e proprio. Infatti, si trovano le pagine:

– Gestioni moduli: nella quale si possono creare i moduli.

– Modelli di piano di studio (formazione): sono i bachelor/master offerti come ad esem-pio Bachelor Informatica. In questi modelli vengono inseriti i moduli.

– Offerta formativa: sono i semestri che contengono i moduli e gli studenti iscritti. – Sessioni di certificazione: dove lo studente riceve una nota una volta fatto un esame.

Capitolo 4

Tecnologie utilizzate

Per questo progetto sono state utilizzate diverse tecnologie: Blockchain fornita dalla piatta-forma Hyperledger (back-end), Angular 7 (front-end) e NodeJS (middleware).

4.1

Blockchain

La tecnologia blockchain è una catena in continua crescita di blocchi che sono legati tra di loro e resi sicuri grazie all’uso della crittografia. Ogni blocco contiene un puntatore (hash code) che si collega al blocco precedente, contiene inoltre un timestamp e i dati della tran-sazione.

Figura 4.1: Esempio Blockchain

Una volta che i dati in un blocco vengono registrati non possono essere alterati senza che vengano poi modificati tutti i blocchi successivi ad esso, invalidando l’intera catena per crear-ne una nuova con le modifiche apportate; questo è possibile solo se il cambiamento è ap-provato da più della maggioranza della rete.

Nella figura a seguire sono mostrate in nero i blocchi della Blockchain validi e in viola i bloc-chi che sono stati invalidati.

8 Tecnologie utilizzate

Figura 4.2: Esempio Blockchain invalidata

In definitiva la Blockchain è un registro distribuito che registra le transazioni da più parti in modo verificabile, permanente e tramite un meccanismo di consenso.

I dati non sono salvati su una singola macchina, ma su più sistemi collegati tra loro tramite una rete peer-to-peer (P2P). Ogni computer collegato alla rete può aggiornare e gestire la catena in modo indipendente, ma sotto il controllo consensuale di tutti i partecipanti (per essere precisi la maggioranza) della rete stessa.

4.2

Hyperledger

Hyperledger è un progetto open source fondato dalla Linux Foundation nel dicembre 2015 con l’obiettivo di portare la tecnologia Blockchain nel settore industriale. In questo progetto è stato utilizzato lo strumento Hyperldeger Composer che, sfruttando il framework Hyperl-deger Fabric, permette di costruire un’applicazione sfruttando questa nuova tecnologia.

4.2.1

Hyperledger Fabric

Fabric è un framework originariamente sviluppato da IBM e inglobato poi all’interno del progetto Hyperledger. L’interessante funzionalità offerta da Fabric è la possibilità di creare una rete privata e permissioned, che permette di gestire le autorizzazioni.

4.2.2

Hyperledger Composer

Composer è uno strumento sviluppato sempre da IBM che permette di semplificare lo svi-luppo di applicazioni blockchain, quindi facilitare la creazione e l’integrazione di queste ap-plicazioni nei contesti aziendali già esistenti.

Questo strumento utilizza le API offerte da Fabric, una sorta di livello più alto, e permet-te di modellare una business network conpermet-tenenpermet-te risorse e transazioni. Per modellare tale rete, bisogna definire delle transazioni che successivamente interagiscano con le risorse. Queste transazioni sono delle funzioni scritte in Javascript.

Figura 4.3: Soluzione Hyperledger

Modellata la rete, la si carica su Fabric generando un pacchetto chiamato Business Network Archive (.BNA). Si può successivamente generare un web-server permettendo di eseguire operazioni CRUD facendo delle chiamate alle API generate.

Figura 4.4: Struttura Hyperledger Composer I principali elementi di una network sono:

10 Tecnologie utilizzate

– Assets: sono le risorse che vengono archiviati nei registri. Possono rappresentare qualsiasi cosa.

– Partecipanti: sono i membri di una business network. Posseggono le risorse e posso-no eseguire transazioni.

– Transazioni: sono il meccanismo con cui i membri interagiscono con le risorse. – Eventi: scatenati con l’esecuzione delle transazioni.

4.3

Angular 7

Angular è una piattaforma open source per lo sviluppo di applicazioni web. E’ stato svilup-pato principalmente da Google nel 14 Settebre 2016.

Le applicazioni sviluppate con Angular sono scritte con il linguaggio tipizzato TypeScript e vengono interamente eseguite nel web browser, ciò implica un risparmio di traffico ogni volta che c’è una richiesta da di un’azione da parte dell’utente.

4.4

NodeJS

NodeJS è una runtime di Javascript Open source mulipiattaforma orientato agli eventi per l’esecuzione di codice Javascript lato server.

Il modello di NodeJS si basa sun I/O event-driven, cioè Node notifica il sistema operativo da quali eventi vuole ricevere notifica e a seguire si mette in attesa, di tali notifiche, nello stato di "sleep". Alla ricezione di una notifica Node si "sveglia" ed esegue il codice di una funzione di callback mappata per l’evento appena verificatosi.

Capitolo 5

Struttura preesistente

La struttura preesistente permette di creare corsi che possono essere aggiunti a dei moduli, quest’ultimi possono essere inseriti in una formazione. La formazione serve a raggruppare i moduli riferiti a un determinato ambito. I moduli infine sono supportati da una certificazione per ogni studente che ha eseguito l’esame.

5.1

Funzionalità

Le funzionalità base implementate sono:

– Creazione, Modifica e Eliminazione degliStudenti.

– Creazione, Modifica e Eliminazione deiDipartimenti.

– Creazione, Modifica e Eliminazione deiCorsi.

– Creazione, Modifica e Eliminazione deiModuli. – Inserire o eliminare Corsi dei Moduli.

– Creazione, Modifica e Eliminazione dellaFormazione. – Inserire o eliminare Moduli della Formazione.

– Creazione, Modifica e Eliminazione deiSemestri. – Inserire o eliminare un Modulo nel Semestre. – Iscrizione di uno Studente in un Modulo.

– Creazione, Modifica e Eliminazione di unaCertificazione.

12 Struttura preesistente

5.2

Back-end

Tutta la struttura del back-end è stata costruita con il framework Hyperledger Composer andando a definire i participant, gli assets e le transaction possibili all’interno della network. Una volta definiti questi elementi è possibile generare il file .bna che consente ai peer della rete l’installazione e l’esecuzione della stessa, nonché l’avvio di un rest-server per poter operare.

5.2.1

Participants

I partecipanti di una rete sono i possessori delle risorse che possono effettuare delle tran-sazioni per scambiarne la proprietà. Per questo progetto sono stati definiti i seguenti parte-cipanti:

– Contact: È un’entità astratta del linguaggio di modelling. È possibile creare delle

enti-tà concrete a partire da questa. Questo partecipante è stato creato con la prospettiva che tutti i partecipanti della network dovrebbero avere delle informazioni di base come nome, cognome, e-mail ed altri.

Gli attributi di questo partecipante sono: un ID, nome, cognome, informazioni di contatto (nr. Telefono, e-mail, domicilio...), data di nascita, nazionalità.

– Student: È un partecipante che estende contact. È la rappresentazione di uno

stu-dente. Oltre alle informazioni di base, sono presenti pure le informazioni relative a: statuto, numero di matricola, un commento e piano di studio associato.

– Collaborator: Rappresenta invece un collaboratore SUPSI. Anche questo estende il

participant contact senza però nessun altro campo aggiuntivo.

Nel modeling language di Composer inoltre, nella definizione di partecipanti, di asset e di transazioni, è possibile per ogni attributo/parametro specificarne la stretta necessità con la keyword optional. Questo permetterà la creazione dell’elemento anche se sprovvisto

dell’attributo opzionale. Non è possibile creare un elemento che non contiene uno dei campi non opzionali.

Prendendo come esempio la figura 5.1, che mostra la dichiarazione del partecipante studen-te, si nota come non sia possibile creare uno studente senza statuto o numero di matricola, ma che sia invece costruibile anche senza specificare immediatamente commento e piano di studio (che verrà aggiunto in seguito per la corretta iscrizione ai semestri e sessioni di certificazione).

L’operatore o sta’ a rappresentare un attributo di tipovalore, mentre l’operatore –> indica

che l’attributo è di tiporiferimento. Il concetto di attributi riferimento/valore è paragonabile

al concetto di puntatore/valore di molti linguaggi di programmazione (C,C++,C#...).

Prendendo da esempio sempre la figura 5.1, una modifica del piano di studio referenziato dallo studente è immediata. Se l’attributo studyPlan fosse stato di tipo valore, la modifica del piano di studio avrebbe comportato la modifica dello stesso in tutti gli studenti, e tutti gli altri asset, che contengono le informazioni relative a quel piano di studio.

5.2.2

Assets

Gli asset definiti per questo progetto sono invece i seguenti:

– Address: È un campo opzionale di un qualsiasi contact. Un contact può avere 0 o

più addresses. All’interno di un address sono presenti: un ID, via, numero civico, CAP, Città, paese, tipo di indirizzo (privato, lavoro...), e-mail, numero telefonico.

– Department: Rappresenta un dipartimento della SUPSI. È composto da un ID e dal

suo nome.

– Course: È l’asset che identifica un corso. È composto da un ID ed il nome del corso.

– Module: È l’asset che identifica un modulo. È composto da un ID, il nome del modulo,

una durata in semestri, numero di ECTS, il dipartimento di riferimento, lo stato, il responsabile, il nome in lingua inglese, un commento e un insieme di corsi del quale il modulo è composto.

– StudyPlan: Rappresenta un piano di studio. Ogni studente deve avere un piano

di studio. Uno studyplan è formato da: nome, dipartimento, stato, commento e un insieme di moduli coi quali il piano di studio è composto. I moduli in questione sono tutti quelli che lo studente dovrà certificare durante la sua formazione per l’ottenimento del titolo di studio.

Uno studyplan ha i seguenti attributi: nome, dipartimento, stato, commento e insieme di moduli.

– Semester: Rappresenta un semestre. Uno studente che è iscritto ad un semestre

è automaticamente iscritto ai relativi moduli che sono di tipo ‘StudentModule’. Un semester è composto da nome, descrizione e insieme di moduli.

14 Struttura preesistente

– StudentModule: Questo asset rappresenta un collegamento fra un modulo e gli

stu-denti che vi sono iscritti. È l’equivalente nella realtà di una classe che segue un modulo durante un semestre. Uno StudentModule è composto da un ID, un modulo ed una lista di studenti iscritti.

– Certification: È l’asset che certifica l’ottenimento di una nota da parte di uno studente

in un modulo. Una certificazione è possibile solo per uno studente che è iscritto ad uno StudentModule che comprenda il modulo che si vuole certificare.

La Certification è composta da un ID, uno studente, un modulo ed un voto.

– CertificationSession: Rappresenta l’insieme di certificazioni emanate in un

seme-stre. Ha i seguenti attributi: nome, dipartimento, semestre, titolo, data ed un insieme di certification.

Figura 5.2: Certification

5.2.3

Transactions

Hyperledger Composer mette a disposizione le operazioni CRUD per ogni asset e partici-pant, ma in questa struttura sono state implementate delle transizioni personalizzate per emulare il comportamento delle operzioni CRUD, in modo da poter tenere il sistema più sotto controllo.

Oltre alle operazioni CRUD sono state create altre transazioni: – AddCourseToModule – RemoveCourseFromModule – AddModuleToStudyPlan – RemoveModuleFromStudyPlan – AddStudentModuleToSemester – RemoveStudentModuleFromSemester – AddStudentToStudentModule – RemoveStudentFromStudentModule

– AddCertificationToCertificationSession – RemoveCertificationFromCertificationSession – SubscribeStudentToSemester

– CreateCertification

5.3

Front-end

Il front-end è stato implementato in Angular 7 in quanto sviluppato dagli sviluppatori di Hyperledger, per la creazione delle pagine web.

5.4

Queries

Sono state implementate una serie di queries attuabili nel database distribuito per il ricavo di dati specifici (filtrati).

Le queries implementate sono: – selectStudentByID – selectStudentByName – selectStudentsBySurname – selectStudentBySerialNumber – selectCoursesByName – selectCoursesByCourseCode – selectModulesByName – selectModulesByModuleCode – selectStudentModuleByModule – selectStudentModuleByModuleName – selectSemestersByName – selectSemestersByModule – selectStudyPlanByName – selectStudyPlanByModule – selectCertificationsByStudent

16 Struttura preesistente – selectCertificationsByStudentName – selectCertificationsByStudentSurname – selectCertificationsByModuleName – selectCertificationSessionsByName – selectDepartmentByName

5.4.1

Problematiche

Il query language di Composer soffre di due problematiche: l’assenza di un operatore LIKE e l’inefficacia del operatore FROM.

5.4.2

Soluzione

Le problematiche appena descritte trovano soluzione, poco ottimale, nel spostare l’imple-mentazione, delle suddette queries, nel client.

5.5

Struttura generale

Nel sistema preesistente la struttura è costituita da due parti principali: back-end e il front-end precedentemente descritto. Il front-front-end manda le richieste al back-front-end(Hyperdger Com-poser e Fabric) a seguito di una interazione da parte dell’utente, il Rest-server risponde. Infine, il front-end mostra i dati ricevuti, in modo compresibile, all’utente.

Capitolo 6

Nuova Struttura

La nuova struttura è costituita dall’aggiunta di un nuovo componente:ilMiddleware. Il

midd-leware è un componente "di mezzo" che si pone tra il front-end (Angular) e il back-end (Hyperledger). Esso ha due compiti:

– Inoltrare le richieste in entrata (front-end,back-end) in uscita (back-end,front-end). – Gestire l’autenticazione role-based.

Figura 6.1: Funzionamento struttura hyperledger-middleware-angular

6.1

Middleware

Il middleware è il componente "di mezzo" scritto in NodeJS tra il back-end e il front-end. Es-so esegue una mappatura di possibili richieste da parte del front-end, e inoltra tali richieste verso il back-end. La risposta ricevuta sarà inoltrata al client. Per poter mappare le richieste e per poter creare un server middleware in ascolto, si è usufruito di un modulo di NodeJS disponibile nei registri di npm chiamatoExpress.

Per il corretto funzionamento dell’intero middleware, sono stati utilizzati altri moduli impor-tanti:

18 Nuova Struttura

– Body-parser: modulo che permette di parsare il body della richiesta e inserirlo nel

componente req.body. Questo per ogni endpoint mappato da Express.

– Cors: modulo che permette il corretto funzionamento del modulo Express usato come

middleware.

– Express-jwt: modulo che permette la convalidazione del token.

– Jsonwebtoken: modulo che permette la creazione del token.

– Underscore: modulo che permette di filtrare un array di json in base a una proprietà.

– Formidable: modulo che permette di fare il parsing di una form-data, utilizzato

prin-cipalmente per l’uploads dei file.

– Fs: modulo che permette la gestione del file-system.

– Http: modulo che permette di fare richieste http verso un determinato url/endpoint.

– Mysql: modulo che permette la gestione di un database.

– Crypto: modulo che permette di criptare una stringa con diversi algoritmi di

criptazio-ne.

– Regex: modulo che permette di creare regex.

Il loro utilizzo verrà spiegato in seguito.

6.2

Divisione in moduli

Lo script di cui il middleware è composto è diviso in moduli in base alla loro funzione, questo permettere: una ricerca, di una eventuale modifica, più efficace e un testing delle procedure più efficente.

Figura 6.2: Struttura in moduli del middleware – api.js contiene le API del Middleware.

– attachment.js contiene le funzioni che gestiscono l’aggiunta, cancellazione di

allega-ti.

– auth-functions.js contiene funzioni personalizzate per gestire i token e la loro validità.

– crypt.js contiene le funzioni di criptazione di stringhe.

– db.js contiene le funzioni per la gestione del database.

– query-server.js contiente API relative alle query.

– roles.js contiene array che descrivono che operazione può fare un determinato ruolo.

– server.js è il centro dell’applicazione e si occupa di chiamare il modulo esatto a

seconda della richiesta ricevuta.

6.3

Autenticazione

Per sistema di autenticazione si intente una infrastruttura che permette di essere ricono-sciuti, in modo univoco, tramite username e password. L’autenticazione è importante ai fini del progetto per poter tracciare chi ha eseguito una determinata operazione, e se ha avuto successo.

Per poter aggiungere la funzionalità d’autenticazione sono stati usati diversi moduli, ma i più importanti sono: Express-jwt, Jsonwebtoken e Mysql, inoltre sono stati aggiunte due

20 Nuova Struttura

endpoint: un endpoint/login e un altro /register.

Per poter usufruire dei modulo di Express-jwt e Mysql è stato necessario impostarli, al con-trario di Jsonwebtoken, definendo per il primo quali route necessitano di autenticazione per accederci e quali no; inoltre è stato necessario impostare il valore secret. Esso è una

stringa che permette di verificare la validità di un token. Questo tipo di convalidazione per-mettere di riconoscere se il token preso in esame è stato rilasciato dallo stesso server. Un altro livello di controllo della validità di un token consiste della sua decriptazione. Descrip-tandolo si devono distinguere due oggetti: uno che contiene la durata di validità del token e l’altro che contiene altre informazioni importanti riguardanti il token stesso. Quest’ultimo è costituito da tre oggetti:

– Header: definisce l’algorimo di cifratura e il tipo del token.

– Payload: contiene le informazioni che sono state inserite durante la creazione del to-ken. Nel nostro caso è stato inserito i dati dell’utente che sta cercando di autenticarsi, cioè:nome, cognome,username, password,ruolo.

– Signature: contiene la firma con cui il server certifica il token (secret) e per questo motivo tramite il secret si può definire se un token è valido o meno.

Se non si riconoscono gli oggetti appena descritti il token è riconosciuto come invalido.

La scadenza del token è anch’essa gestita dal modulo Express-jwt. Esso gestisce un data-base con all’interno la lista dei token validi e non scaduti; tramite un test riesce a definire la scadenza di un token, e se questo accade, lancia un errore token expired.

Per Mysql è stato necessario impostare il database di riferimento.

Database Il database è utilizzato per contenere i dati riferite alle persone che vogliono

effetturare il login (nome,cognome, username, password e ruolo).

Per la creazione del database è stato usatoXAMPP. XAMPP è una piattaforma software

che permette la creazione di un server di gestione di un database PhpMyAdmin.

Il middleware per poter intercettare le richieste di login e di registrazione necessita dell’ag-giunta dei due endpoint. Nell’endpoint di registrazione vengono inseriti nel database i dati riguardanti l’utente ricevuti nel body della richiesta Http. Tutti i campi vengono inseriti in chiaro tranne la password che viene criptata tramite il moduloCrypto. Con Crypto è

possi-bile definire le carattaristiche e il tipo di algortmo di cifratura da utilizzare.

Nell’endpoint di login viene preso l’utente dal body della richiesta e viene comparata la sua password con quella salvata nel database per il corrispettivo utente. Una volta effettuato il login, il middleware crea un token tramite il modulo Jsonwebtoken e lo rimanda al front-end

che si occuperà di salvare il token nello storage locale del browser. Al contrario dell’endpoint di login quello di registrazione è accessibile solo se ruolo dell’utente, che ha fatto il login, è tipo Admin.

Una volta aggiunto la funzionalità al middleware è stato necessario aggiungere il punto di accesso a questa funzionalità in Angular, aggiungendo due componenti (login, register) e modificando i service in modo che nell’header di ogni richiesta fosse presente il token salvato nel local storage del browser.

Figura 6.3: Form di Login

22 Nuova Struttura

L’autenticazione che si vuole in questo progetto è di tipo role-based, perciò ad ogni opera-zione mappata nel middleware si è aggiunta una callback di accesso chiamata Authorize. Essa fa in modo che solo le persone con un determinato ruolo possono eseguire una speci-fica operazione. La mappatura ruolo-operazione è gestita in un modulo Javascript chiamato role.js.

Figura 6.5: Funzione authorize()

La funzione ha come paramentro un array di ruolo che possono accedere all’operazione che si sta verificando. Esso verifica se il ruolo dell’utente che ha fatto la richiesta è all’in-terno dell’array dei ruoli ammissibili, se da test positiva continua con l’esecuzione, altrimenti restituisce un’errore di tipo Unauthorized 401.

Per poter ternere traccia di ogni operazione avvenuta nel sistema e poterla registrare, si è creata un funzione (printOperation()), inserita in ogni callback di API del server che delle query, che registra l’operazione, username dell’utente che ha effettuato la richiesta, la data e l’ora e se l’operazione ha avuto successo.

Figura 6.6: Oggetto salvato nel log delle operazioni

Figura 6.7: Funzione printOperation()

6.4

Gestione Utenti

E’ stata implementata la gestioni degli utenti in modo che un utente di tipo Admin possa: vedere gli utenti che possono avere accesso al sistema e eliminare gli utenti. Per fare questo sono stati aggiunti due endpoint mappati in modo da gestire la richiesta get della lista degli utenti, e un’eventuale eliminazione. Le due richieste ricevute dal server e gestite da due funzioni: getUser() e deleteUser(). Entrambi creano query in modo da mandare richieste di visualizzazione e di eliminazione degli users.

24 Nuova Struttura

Figura 6.8: Funzioni di delete e get degli users

Inoltre è stato aggiunto una sezione nella navbar per permette all’admin la gesitoni di questi. Se l’utente, che affettua l’accesso, non è un Amministratore la sezione non è ne accessibile ne visibile.

Figura 6.9: Navbar con Gestione Utenti

Figura 6.10: Form per la gestione Utenti

6.5

Funzionalità di ricerca ottimizzata

Con la creazione del Middleware è possibile risolvere il problema dell’assenza o mancato funzionamento del FROM e LIKE. Nella versione precedente la soluzione è costituita nel spostare la logica nel client, ma con la presenza del middleware è possibile spostare in essa la logica di filtraggio delle query, aumentado la velocità di risposta della ricerca. Per fare ciò, è stato necessario aggiungere un’ulteriore mappatura nel middleware per poter gestire le richieste di tipo query e inserendo nelle callback di gestione il comportamento che ogni richiesta avrebbe dovuto avere.

26 Nuova Struttura

Figura 6.11: Mappatura query nel server

Figura 6.12: Esempio query: ricerca dello studente per nome

Tutte le funzioni riguardante le query sono inserite all’interno del file query-server.js.

6.6

Reporting

Per reporting si intende mostrare al cliente le certificazioni relative a un determinato studente ed eventualmente stamparle. Per poter implementare questo si è dovuto creare punto di connesione al middleware in modo da ricevere le certificazioni relative a un singolo studente.

Per poter eseguere questo nella callback di gestione di tale endpoint, viene richiesto al Rest-server tutte le certificazioni. Una volta ricevute, è stato possibile filtrare l’array json ricevuto tramite il moduloUnderscore che filtra un array Json in base a una proprietà di un oggetto

di tale array: in questo caso si è utilizzato il codice identificativo dello studente (contactID) come proprietà di filtraggio.

Per poter mostrare il risultato all’utente, è stato necessario aggiungere il dato acquisito nel client, nel componente di dettaglio dello studente.

Per poter stampare è stato necessario eliminare gli elementi da non stampare dalla pagina HTML utilizzando il querySelector e il DOM. Una volta ottenuto la pagina da stampare è stato sufficente chiamare il metodo di window, chiamato print(), che stampa il contenuto della pagina HTML corrente.

28 Nuova Struttura

Figura 6.14: Form student-detail

Cliccando sull’icona di stampa comparira una dialog di stampa:

6.7

Allegati

Per poter aggiungere gli allegati è stato necessario modificare il file business network del Rest-server, e quindi, creare un’altra versione con il campo Attachments nel model Studen-ts.

Attachments è un array di stringhe che identifica il nome dei file allegati a un determinato studente. Non c’è nessun vincolo sul tipo del file che si importa, l’importante è che il nome del file non contenga spazi. la gestione degli allegati dello studente viene gestita in Angular dal componente student-detail, il quale durante la fase di costruzione dell’oggetto farà ri-chiesta dello studente preso in esame al Rest-server passando per il middleware. Una volta ricevuto lo mostrerà nell’applicazione web:

Figura 6.16: Form student-detail con eliminazione allegato

Figura 6.17: Form student-detail con aggiunta di allegati

Con l’aggiunta dell’allegato si è implementato anche la rimozione di tale allegato. Questo è stato gestito aggiungengo un bottone rimozione per ogni allegato nel client e aggiungendo nel middleware l’endpoint con corrispettiva callback di rimozione.

6.8

Miglioramento dell’interfaccia web

Per il miglioramento dell’interfaccia web si è preso come riferimento l’attuale versione di Tiforma nella versione Windows utilizzata dalla SUPSI. Questo per rendere facile una pos-sibile integrazione futura nel sistema, e per un facile apprendimento sullo schema di utilizzo per persone che hanno avuto già esperienza con Tiforma.

30 Nuova Struttura

Figura 6.18: Interfaccia Tiforma

Capitolo 7

Test

Per testare il corretto funzionamento dell’infrastruttura è stato creato un script bash auto-matico. Lo script effettua le richieste al Middleware come se fosse il front-end progettato ad effettuare le richieste. Le invocazioni HTTP vengono fatte tramite il comandocurl e in base

al valore di ritorno (0-ERROR else-SUCCESS) viene stampato a schermo la procedura e l’esito di quest’ultima.

Figura 7.1: Procedura che crea uno studente tramite curl

Ogni procedura testata è chiamata due volte all’interno dello script per testare il corret-to funzionamencorret-to dell’autenticazione, perciò le funzioni vengono invocate inserendo nel-l’header, nella proprietà "Authentication", una volta il token giusto (preso tramite una previa autenticazione) e un’altra volta il token sbagliato.

32 Test

Figura 7.2: Test createStudent()

Figura 7.3: Esempio test output

Per poter chiamare lo script di test deve essere passato come paramentro un token valido in modo da poter effettuare le richieste all’interno dello script. Per poter testare il front-end sono stati creati i file spec.ts che effettuano i test sulla funzionalità di un determinato componente.

Capitolo 8

Pianificazione e gestione

La pianificazione e la gestione del lavoro è stata gestita con un applicativo chiamato Trello. Tramite l’applicazione si è potuto tener traccia del lavoro svolto e di quello che manca. Il lavoro è stato distribuito secondo il tempo prestabilito (dal 10.06.2019 al 30.09.2019) defi-nendo per ogni requisito le task che lo compopevano. Trello permette di definire la durata di lavoro per ogni task in modo da poterlo mostrare tramite un diagramma di Gannt. La gestio-ne del lavoro è stata pianificata in questo modo (vedi figura a seguire) dando una settimana di "buffer" per necessità extraoridinarie.

Capitolo 9

Sviluppi futuri

Ci sono alcuni aspetti che si sarebbero voluti sviluppare durante l’arco del tempo dedicato per il progetto di tesi. In particolare, un sistema di gestione di recupero password e un sistema di controllo sui campi.

9.1

Recupero Password

Come ogni sistema di autenticazione sarebbe stato interessante avere un sistema di recu-pero password nei casi in cui l’utente non ricorda le sue credenziali. Nel sistema attuale l’unica forma di recupero password è il contattare l’admin di sistema.

9.2

Controllo sui campi

Al momento, l’utente può inserire qualsiasi valore all’interno dei campi si creazione degli asset, questo non dovrebbe essere permesso in quanto potrebbe creare dati incosistenti. Inoltre il mancato controllo dei campi provoca un "buco" nella sicurezza in quando il sistema in queste condizioni soffre diSQL Injection.

Capitolo 10

Conclusioni

L’applicazione è soddisfa tutti i requisiti impostati all’inizio del progetto. Oltre alle funzionalità già presenti nel sistema preesiste, sono state aggiunte ulteriori funzionalità pratiche e che rendono l’applicazione più completa per un futuro utilizzo nel mondo reale. Il sistema map-pando ogni funzionalità e scrivendo per ogni accesso ad ognuna un nuovo oggetto nel file di log, permette di capire chi ha cercato di fare una determinata operazione e se ha avuto successo o meno. Il sistema inoltre riconosce gli errori e permette di avere un determinato comportamento in conseguenza di esse.

Il sistema necessita ancora di modifiche e aggiunte per poter essere messo in produzione, ma ora, oltre a dare funzionalità base di gestione di un sistema universitario permette di gestire l’autenticazione di persone che applicano modifiche nella blockchain.

Nel complesso il progetto mi ha permesso di acquisire conoscenze pratiche sulla block-chain, sul framework di Angular e di NodeJS. Il progetto mi ha permesso di consolidare co-noscenze su diversi linguaggi (HTML, TypeScript, Javascript) e approfondire le coco-noscenze sulla gestioni delle dipendenze e modulistica di npm.

Bibliografia

1. Hyperledger https://www.hyperledger.org 2. Hyperledger Fabric https://www.hyperledger.org/projects/fabric 3. Hyperledger Composer https://hyperledger.github.io/composer/latest/ 4. Angular 7 https://angular.io 5. Bootstrap https://getbootstrap.com

6. Material Icons Guide

https://google.github.io/material-design-icons/ 7. NodeJS https://nodejs.org/en/ 8. Blockchain https://www.ibm.com/blockchain 9. TypeScript https://www.typescriptlang.org 10. Manuale Tiforma

Capitolo 11

Manuale d’installazione

11.1

Installazione Hyperledger

Per poter installare correttamente Hyperledger è necessario installare preventivamente i requisiti. Per fare ciò si richiamano i comandi sotto descritti.

c u r l −O h t t p s : / / h y p e r l e d g e r . g i t h u b . i o / composer / l a t e s t / prereqs−ubuntu . sh chmod u+x prereqs−ubuntu . sh

. / prereqs−ubuntu . sh

Di seguito si installerà l’Essential CLI Tools: npm i n s t a l l −g composer−cli@0 . 2 0 Le utility per poter eseguire il Rest-server:

npm i n s t a l l −g composer−r e s t−server@0 . 2 0 Le utility per la generazione di assets:

npm i n s t a l l −g g e n e r a t o r−h y p e r l e d g e r−composer@0 . 2 0 Yeoman necessario per generator-hyperledger-compose:

npm i n s t a l l −g yo

Playground in modo da poter modificare e testare il business network: npm i n s t a l l −g composer−playground@0 . 2 0

Hyperledger Fabric:

m kd i r ~ / f a b r i c−dev−s e r v e r s && cd ~ / f a b r i c−dev−s e r v e r s

c u r l −O h t t p s : / / raw . g i t h u b u s e r c o n t e n t . com / h y p e r l e d g e r / composer−t o o l s / master / packages / f a b r i c−dev−s e r v e r s / f a b r i c−dev−s e r v e r s . t a r . gz t a r −x v f f a b r i c−dev−s e r v e r s . t a r . gz

42 Manuale d’installazione

e x p o r t FABRIC_VERSION= h l f v 1 2 . / downloadFabric . sh

11.2

Installazione Middleware

Per il corretto funzionamento del Middleware basta installare i moduli utilizzati da questo componente. Ciò è possibile scrivendo il comando di npm con il terminale posizionato nella cartella dove è presente il .json del middleware:

npm i

11.3

Installazione Front-end

Per il corretto funzionamento di Angular, nel caso di questo progetto, è necessario installare Angular stesso e le sue dipendenze.

Angular:

npm i n s t a l l −g @angular / c l i

Per installare le dipendenze di material-design-icon e bootstrap: npm i n s t a l l m a t e r i a l−design−i c o n s

Capitolo 12

Manuale di attivazione del sistema

Insieme al progetto sono stati aggiunti due script per l’attivazione dell’intero sistema dopo che è stato installato.

Il primo script si occupa di far partire in modo corretto il server, perciò si occupa della ge-stione della card (necessaria per l’accesso) e a far partire il sistema di back-end tramite il business network.

Per il corretto funzionamento di tale script è necessario utilizzare una versione di node non superiore alla versione 8, in quanto Hyperdger è compatibile solo con essa.

Il secondo script si occupa invece si attivare il database per il back-end, utilizzato per la gestione dei profili utente. Per rendere operativo il sistema si necessità di far accendere il middleware tramite il comando:

node s e r v e r . j s

Infine per poter attivare anche il client è necessario andare nella cartella del progetto di Angular e scrivere nel terminale:

Capitolo 13

Manuale d’uso

13.1

Login

Il login è il compomente visibile e accessibile all’apertura dell’applicazione. Ad esso si de-vono inserire le credenziali date da un amministratore (Admin). Una volta effettuato il login è possibile accedere alle diverse funzionalità.

13.2

Menù

Il menù principale è situato a sinistra ed è sempre visibile. Da questo menù è possibile cliccando(se si è effettuato il login), navigare verso 8 diverse sezioni: Studenti, Dipartimenti, Corsi, Moduli, Formazione, Semestre, Certificazione, Ricerca. Oltre a queste, se si è fatto il login è possibile vedere anche l’opzione Logout e Registrazione (se si è fatto l’accesso con un account di tipo Admin), che permette di registrare nuovi utenti che possono accedere alla rete.

In ciascuna sezione, ad eccezione di quella della ricerca, registrazione e logout, è possibile creare, modificare, eliminare ed ottenere informazioni sugli elementi che la sezione tratta. Le informazioni sull’elemento sono direttamente reperibili alla selezione dello stesso dalla lista. Queste stesse possono essere modificate direttamente ed essere salvate con il click sul pulsante verde “salva”.

Le informazioni sull’elemento possono essere stampate cliccando sull’icona della stampan-te.

L’elemento può essere rimosso completamente dal database effettuando un click sul pul-sante rosso elimina.

Un nuovo elemento può esser creato cliccando sul tasto di aggiunta presente sopra ogni lista di elementi.

Nella sezione Studenti, cliccando sul bottono Certicazioni, è possibile vedere le certicazioni relative al determinato studente, e se si clicca il bottone di stampa dopo aver visualizzato le

46 Manuale d’uso

certificazioni è possibile stampare, oltre le informazioni relative allo studente, anche le sue certificazioni.

13.3

Studenti

Per gli studenti è possibile operare sui seguenti dati: nome, cognome, numero di matri-cola, statuto (Immatricolato, Mai immatricolato, Exmatricolato, ospite), la data di nascita, nazionalità, piano di studi e commento.

13.4

Dipartimenti

I dipartimenti sono formati esclusivamente dal loro nome.

13.5

Corsi

Un corso è formato da un codice di corso ed un nome.

13.6

Moduli

Un modulo è formato da un codice di modulo, un nome, una durata (in semestri), una quantità di ECTS assegnati agli studenti che certificano il modulo, un dipartimento di appar-tenenza, uno stato, un commento ed un insieme di corsi con i quali il modulo si compone.

13.7

Formazione

In questa sezione vengono trattati i piani di studio. Un piano di studio è composto da un dipartimento di appartenenza, uno stato, un commento ed un insieme di moduli dei quali il piano di studio si compone.

13.8

Semestre

Un semestre contiene informazioni relative al nome, una descrizione ed un insieme di moduli ai quali è correlata pure l’informazione relativa agli studenti iscritti a tali moduli.

13.9

Certificazione

Una certificazione è un dato che associa uno studente ad un voto in un modulo. La certifi-cazione è composta da uno studente, un modulo ed un voto decimale che va’ da un minimo di 1 ad un massimo di 6. Nota: È possibile creare delle certificazioni per uno studente solo

se lo studente è collegato al modulo nel suo piano di studio e solo se lo studente è iscritto a tale modulo.

13.10

Ricerca

Questa particolare sezione si distingue dalle altre per il fatto che il suo scopo sia quello di trovare degli elementi in base a criteri ben specifici. Di seguito, una tabella che riassume quali elementi sono individuabili (prima colonna) in base a quali parametri (prima riga).

Figura 13.1: Possibili ricerche

Sotto la voce tipo è possibile selezionare il tipo dell’elemento ricercato, mentre sotto la voce filtro è invece possibile scegliere il criterio di ricerca. Inserendo poi il valore del criterio sotto la voce valore e cliccando sul pulsante blu Cerca, si ottiene una lista di elementi che rispettano i parametri di ricerca.