Tesina ITS final

Sviluppo di un applicazione web sicura e scalabile per la commercializzazione di un prodotto innovativo

�

�

Tecnico superiore per i metodi e le tecnologie per lo sviluppo di sistemi software

Anno Formativo: 2015/2016

“Sommozzatori, cinture programmabili e vendita on-line”

Sviluppo di un applicazione web sicura e scalabile per la commercializzazione di un

prodotto innovativo

Alessio Cozzolino

!1


INDICE

SOMMARIO

L’ AZIENDA

1. Presentazione dell’ azienda

2. Settore di attività

PROGETTO REALIZZATO

4. Descrizione del prodotto

5. Esigenze del cliente e Specifiche del progetto

6. Il processo di analisi e sviluppo dell’ applicazione

6.1. Definizione dell’ MVP (Minimal Valuable Product)

6.2.Traduzione in termini tecnici dei bisogni del cliente

6.3. Presentazione dell’ architettura dell’ infrastruttura software sviluppata

6.3.1.Descrizione del modello architetturale

6.3.1.1. DAO (Data Access Object)

6.3.1.2. BL (Business Logic)

6.3.1.3. ROUTES (Application’s Endpoints )

6.3.1.4. Web Server & Virtual Hosts

6.3.1.5. Client

3.3.2. Motivazione delle scelte operate

6.4. Descrizione del Workflow, gestione del tempo e delle risorse

7. La scelta delle tecnologie

7.1. Database Design

7.1.1. Diagramma Entity Relationship

7.2. Descrizione delle tecnologie Server-side

7.3. Descrizione delle tecnologie Client-side

7.4. Versioning

7.5. Deployment

!2


8. Funzionalità sviluppate

8.1. Registrazione e login

8.2. Login con i social

8.3. Gestione account utente

8.4. Content Management System(CMS)

8.5. Funzionalità e-commerce

8.5.1. Carrello

8.5.2. Check out

8.5.3. Pagamento

9. Sicurezza

9.1. Input validation e SQL Injection

9.2. Man In The Middle Attacks(MITMA)

9.3. Sicurezza nei pagamenti

9.4. Autenticazione

9.5. Sicurezza sulla base dati

RISULTATI CONSEGUITI

CONSIDERAZIONI FINALI E RINGRAZIAMENTI

!3


SOMMARIO

Quello che mi propongo di descrive in questa relazione è la mia esperienza di Stage Erasmus+ nel Regno Unito.

Descriverò il lavoro svolto, l’ ambiente in cui mi sono trovato ed in che modo questa esperienza abbia contribuito alla formazione della mia figura professionale.

L’ applicazione che ho sviluppato è un e-commerce che ha il fine di commercializzare una particolare invenzione che la mia azienda ospitante ha sviluppato all’ interno di quello che potrebbe essere definito, il suo reparto di “ricerca e sviluppo”.

Ho sviluppato l’ applicazione da solo, data l’ assenza di personale qualificato all’ interno dell’ azienda, questo significa che ho dovuto vestire i panni del Full Stack Web Developer* e del Sistemista.

Questo mi ha portato a dover cercare un approccio che mi consentisse di “non re-inventare la ruota”, dato il poco tempo a mia disposizione, e di scegliere delle tecnologie che proponessero dei modelli e delle linee guida solide e documentate da poter implementare “senza sorprese”.

Il mio tutor è stato più che altro un committente, e questo mi ha insegnato come gestire autonomamente il tempo e come organizzare e portare a termine lo sviluppo di un applicazione complessa come un e-commerce.

Oltretutto ho imparato ad imparare sfruttando i vari strumenti messi a disposizione da internet per i programmatori (i.e. Stack Overflow, la community di NPM e Github e la documentazione ufficiale delle tecnologie che ho utilizzato).

Sono riuscito a portare a termine lo sviluppo dell’ applicazione, operando delle scelte e dei sacrifici che verranno descritti più avanti, ma riuscendo a consegnare un prodotto finito e funzionante e pubblicato all’ url: www.hydrofly.co.uk

___________________________________________________________________________

*Full Stack Developer - Sviluppatore polivalente con familiarità nello sviluppo e nella

progettazione di tutte le parti che compongono un applicazione, dal Database alla User Interface. -

Wikipedia.

!4

http://www.hydrofly.co.uk


L’ AZIENDA

1. Presentazione dell’azienda

Dynamic Laser Solution l.t.d. è una piccola azienda a gestione familiare situata a Gosport, UK fondata nel 2009.

L’ azienda è gestita da Marek Mamczur, ingegnere meccanico, inventore e fondatore dell’azienda, e da suo padre.

L’ idea di fondare quest’ azienda nasce dalla volontà di Marek di commercializzare una sua invenzione, una macchina a laser per il livellamento di giroscopi.

2. Settore di attività

Il core business dell’ azienda, nei primi anni di attività è stato la vendita dei suddetti macchinari, ed il settore a cui si rivolgeva era principalmente quello militare, per l’ equipaggiamento di droni.

Dato che questo tipo di prodotti è molto di nicchia l’ azienda ha avviato vari side-businesses. Il principale è la produzione di quadri elettrici per piccole aziende ed industrie della zona, di questo si occupa il padre di Marek, che gestisce il reparto di Elettrotecnica insieme ad un collega ed amico di vecchia data.

Occasionalmente, quando le moli di lavoro sono elevate, vengono chiamate varie altre persone ad aiutare.

Secondariamente l’ azienda ha avviato un piccolo reparto che potremmo definire di “ricerca e sviluppo” che è gestito da Marek e nel quale vengono impiegati i numerosi stagisti che l’ azienda si propone di ospitare.

!5


PROGETTO REALIZZATO

1. Descrizione del prodotto

Il progetto realizzato è consistito nello sviluppo di un applicazione web e-commerce per la commercializzazione di una cintura lampeggiante, impermeabile e programmabile per sommozzatori.

La cintura risolve vari problemi tra cui l’ identificazione della persona, che può talvolta essere difficile in condizioni di buio e/o scarsa visibilità.

Si propone inoltre di offrire sussidio nel caso in cui si verifichi una situazione di pericolo permettendo, tramite un apposito pulsante, l’ attivazione di una modalità in cui la cintura lampeggia ripetutamente in tutti i colori della sua configurazione fino all’ esaurimento della batteria.

I colori programmabili sono 5: Rosso, Giallo, Verde, Blu, Viola.

La cintura consiste in una Motherboard equipaggiata con un sensore touch e un ricevitore NFC, che viene sfruttato anche per ricaricarne le batterie, tramite apposita base. Offre pertanto una completa impermeabilità. Viene programmata tramite un applicazione Android che consente di selezionare il colore e l’ intervallo nel quale essa deve lampeggiare ed è attivata e disattivata con il tocco.

2. Esigenze del cliente e specifiche del progetto

Il mio tutor non aveva esperienza nello sviluppo web e in casa non c’era nessuno sviluppatore in grado di costruire un applicazione di questo tipo, pertanto il mio rapporto con lui può essere configurato come quello tra un committente ed un esperto di IT.

Il cliente mi ha informato della sua volontà di avere un sito in HTML5, visualizzabile correttamente su tutti i dispositivi, in cui si potessero acquistare prodotti, avere un carrello e pagare tramite carta di credito o prepagata.

Mi ha inoltre informato della sua volontà, in futuro, di ampliare lo store con vari altri prodotti e che avrebbe voluto anche aggiungere alla app mobile alcune delle funzioni presenti sul sito web.

!6


3. Il processo di analisi e di sviluppo dell’ applicazione

Non essendo affiancato da un team ho dovuto occuparmi di sviluppare tutto lo stack dell’ applicazione, dal design del Database allo sviluppo della User Experience / User Interface.

Pertanto ho ritenuto opportuno capire quali fossero i reali bisogni del cliente e concordare con lui una soluzione che mi consentisse di consegnare un prodotto finito, funzionante e facilmente migliorabile alla fine del periodo di tirocinio.

Durante la prima settimana ho effettuato uno studio su quali fossero le features principali di cui necessita un sito web di questo tipo.

Lo studio si è svolto principalmente analizzando le funzionalità offerte dai siti e-commerce più famosi come amazon.com ebay.com zalando.com apple.com ed in che modo queste funzionalità potessero essere di utilità nel nostro caso specifico.

Ho anche effettuato uno studio su e-commerce di start ups in una condizione simile a quella di Dynamic Laser Solutions, e mi sono imbattuto in un sito web che vende del silicone colorato per rivestire gli auricolari ed evitare che essi cadano se si usano durante lo sport.

www.earcandi.co.uk

Da quest’ ultimo ho tratto ispirazione per il design della UI del sito web.

3.1 Definizione dell’ MVP ( Minimal Valuable Product)

Dopo un attenta analisi si è evinto che, ciò che più interessava al cliente erano le seguenti funzionalità:

!7

• Sito web responsive con una UI accattivante e UX ottimizzata

• Vetrina prodotti • Carrello • Checkout • Notifiche via email • Registrazione account utente • Login con i social • CMS per la gestione degli ordini e

dei prodotti

http://amazon.com

http://ebay.com

http://zalando.com

http://apple.com

http://www.earcandi.co.uk


Aveva però espresso anche la volontà di creare un modo per consentire al cliente di registrare il suo prodotto tramite un codice seriale e di creare un sistema che potesse consentire a chiunque trovi una cintura Hydrofly smarrita di potersi accordare con il proprietario per la restituzione.

E’ stato fatto subito presente che il tempo non sarebbe stato sufficiente a sviluppare queste funzionalità ma sono state comunque tenute in considerazione nello sviluppo dell’applicazione, che è stata predisposta per la loro futura implementazione.

3.2 Traduzione in termini tecnici dei bisogni del cliente

Le necessità del cliente implicano oltre allo sviluppo di funzionalità per la gestione del catalogo e degli ordini, la risoluzione di diversi problemi riguardanti la sicurezza del sito web, dei pagamenti e dei dati dell’ utente.

Oltretutto, il cliente non disponeva di un database per la vendita dei prodotti.

La necessità di voler sviluppare un applicazione mobile che includesse alcune delle funzionalità presenti all’ interno del sito si traduce con lo sviluppare un back end ibrido, che possa essere adattato ai diversi bisogni del cliente.

Per soddisfare queste necessità ho ritenuto opportuno lo sviluppo di una WEB API che si occupasse di esporre i dati presenti sul database gestionale dell’ e commerce e di procedere con un approccio allo sviluppo modulare.*

3.3 Filosofia di sviluppo dell’ applicazione

L’ applicazione è stata progettata e sviluppata tenendo a mente, data la configurazione dell’ azienda, la necessità di manutenzione e sviluppo ulteriore da parte di stagisti. E’ stata quindi posta molta attenzione sulla semplicità di comprensione del codice ed è stata ampiamente utilizzata, per questa ragione, la filosofia di sviluppo DRY(Don’t Repeat Yourself); che è uno dei constraint principali per la scrittura di codice manutenibile e di qualità secondo Andy Hunt e Dave Thomasn, come descritto nel loro libro The Pragmatic Programmer**.

« Ogni elemento di conoscenza deve avere una sola, non ambigua, autorevole rappresentazione all'interno di un sistema. » - Andy Hunt

!8


3.3 L’ architettura dell’ infrastruttura software sviluppata

L’ architettura dell’ infrastruttura software è stata sviluppata come segue:

Il modello descrive il flow dei dati (Data Flow) durante un ciclo di interazione tra server e database.

Tutti i livelli dell’ applicazione sono indipendenti tra di loro, ogni livello interagisce attivamente solo con il primo strato del livello antecedente ed ignora tutto ciò che avviene negli altri livelli compresa la loro esistenza. (3.3.1)

Ogni modulo ha senso di per se e non necessita dell’ esistenza degli altri per portare a termine lo scopo per cui è stato sviluppato.

Espone due interfacce*, una in ingresso ed una in uscita, che consentono di ricevere input e di emettere output.

Si divide inoltre in un numero di micro-moduli indipendenti per operare un ulteriore suddivisione dei compiti, consentendo in questo modo il più alto grado di isolamento, testability, manutenibilità sicura e riusabilità del codice. (3.3.3) ___________________________________________________________________

*Programmazione Modulare: In informatica la programmazione modulare è un paradigma di programmazione che consiste nella realizzazione di programmi suddivisi in moduli, ognuno dei quali svolge precise funzioni. - Wikipedia. **The Pragmatic Programmer - https://it.wikipedia.org/wiki/Pragmatic_Programming ***Interfaccia - Il termine non fa riferimento al concetto di Interfaccia della programmazione orientata agli oggetti(OOP). Si propone di descrivere un’unità logica attraverso la quale il sistema isolato di cui è composto il modulo ha la possibilità di dialogare con l’ esterno(I/O).

!9

Database DAO BL ROUTES Application’s Web Server

Fig. 1

Data Access Layer Business Logic API Endpoints

API

https://it.wikipedia.org/wiki/Pragmatic_Programming


3.3.1 Descrizione del modello architetturale

3.3.1.1 DAO: Data Access Object.

Insieme di moduli che si occupano di interrogare la base dati.

STRUTTURA DEL DATA ACCESS

il DAO si suddivide in vari moduli per l’ accesso a specifiche entità nel database, che vengono raggruppati poi in un solo oggetto, “db-manager”, che espone le funzionalità per l’ accesso ai dati.

Le query sono effettuate nel più basso degli strati, il più vicino al database.Questo livello contiene un metodo query generico che è l’ endpoint di tutte le richieste al database, siano esse richieste GET, POST, PUT o DELETE. Gli statement vengono preparati dal livello superiore e poi inviati a dao.js per l’ esecuzione.

I vari moduli contengono la preparazione degli statements SQL.

La gestione degli errori è demandata alla funzione chiamante i metodi di accesso ai dati, nel nostro caso, il BusinessLogic Layer. Questo per tener fede alla filosofia modulare con la quale è stata sviluppata l’ intera infrastruttura.

!10

db-managermodulesdata access object

envelopes and exposesusesaccess data

Fig. 2


3.3.2.2 BL: Business Logic

il DataAccess si occupa soltanto di recuperare o inserire dati nel database, tutto il lavoro sui dati in ingresso e in uscita e la gestione di eventuali errori viene effettuata dal Business Logic layer(BL).

BL sfrutta i metodi che vengono esposti dal modulo “db-manager” per l’ accesso ai dati.

Non tutti i dati hanno bisogno di essere lavorati, in alcuni casi BL si limita a fare da tramite tra ROUTES e DAO.

Il motivo per cui si è scelto questo approccio è per dividere il più possibile i compiti e dare adito a future implementazioni nel quale debba essere effettuato un lavoro non previsto su alcuni dati.

Nei set di moduli che appartengono alla Business Logic vengono quindi gestiti:

• Ordini

• Prodotti

• Utenti

• Sicurezza ed autenticazione

• Pagamenti, dialogo con le API del Payment Gateway e gestione della sicurezza dei pagamenti.

!11

db-manager modules bl

uses envelopes and exposesaccess data

Fig. 3


3.3.2.3 ROUTES: Application’s Endpoints

Il modulo Routes è il luogo in cui sono definite tutte le “rotte” verso le tabelle del database.

L’ API è stata sviluppata cerando di attenersi il più possibile al Richardson’s Maturity Model.*

E’ quindi RESTful poiché cerca di rispettare tutti i constraint della REST applications architecture.

1. L’ accesso ai dati è organizzato in risorse individuali indipendenti ed ognuna è raggiungibile ed esposta da una specifica route dell’ API.

2. Sono sfruttati tutti i verbi dell’ HTTP

3. l’ API con cui dialoga il server web dell’ applicazione è STATELESS**

*Richardson Maturity Model - Modello sviluppato da Leonard Richardson che descrive i principali elementi dell’ approccio REST allo sviluppo di Application Programming

Interfaces, e lo suddivide in tre punti principali:

• gestire la complessità dell’ applicazione applicando un approccio “DIVIDI ET IMPERA”, scomponendo grandi endpoint in tante piccole risorse

• standardizzare l’ utilizzo dei verbi dell’ http per gestire tutte le situazioni in maniera analoga eliminando superflua complessità e variazioni non necessarie.

• rendere l’ API facilmente consultabile facendo in modo che essa sia molto esplicativa di per se(discoverability principle, making the protocol used self-documenting)

**Stateless - Si definisce in questo modo un protocollo di comunicazione che tratta ogni richiesta come una transazione indipendente e slegata da ogni precedente e successiva richiesta in modo che la comunicazione tra le parti consista soltanto in uno scambio di di richiesta e risposta. Utilizzando questo tipo di modello, nessuna assunzione viene fatta sullo stato dell’ applicazione né dal client né dal server.

!12


3.3.3 Motivazione delle scelte operate

Questo approccio è stato scelto per favorire la manutenibilità e la scalabilità* dell’ applicazione.

I moduli non sono interdipendenti e costituiscono delle unità logiche che hanno senso “di per se”; quindi qualsiasi modifica o sostituzione di una delle parti dell’ applicazione comporta un intervento di modifica minimo e in alcuni casi nullo sul resto dello stack.

Se dovessimo ad esempio decidere di cambiare DBMS, supponendo che la struttura dello stesso rimanga invariata, l’ unico modulo che ne risentirebbe sarebbe nel dominio di DAO e più specificamente quello che si occupa di lanciare le query sulla base dati, ed ha quindi bisogno dei driver per accedere alla stessa.

Con riferimento alla Fig.2 si può notare che le modifiche andrebbero apportate solo sul “data access object”, nessuna modifica dovrebbe invece essere apportata a “modules” e “db-manager”. Grazie a questo approccio, una modifica così sostanziale risulterebbe quindi trasparente per quasi tutta l’ infrastruttura software.

Un altro vantaggio che questo approccio offre è la facilità con la quale possono essere testate le varie parti da cui è composta l’ applicazione, garantendo una granularità molto elevata.

Inoltre la suddivisione dell’ applicazione in unità logiche ed il livello di astrazione molto elevato, in coesione con un accurata scelta dei nomi delle varie entità e della definizione di una naming convention, rendono più semplice la comprensione dell’ applicazione.

La scelta di sviluppare un API è stata data dalla volontà del cliente di interagire con i dati attraverso diversi dispositivi. 3.3.3.1 Downsides dell’ approccio scelto

I trade-offs principali che impone questo approccio sono prestazionali e di tempo di sviluppo.

3.3.3.2 Gestione dei downsides

Questi lati negativi sono stati gestiti operando delle scelte tecnologiche adeguate e degli accorgimenti nello sviluppo dell’ infrastruttura software.

!13


4. LA SCELTA DELLE TECNOLOGIE

Le tecnologie da scegliere per lo sviluppo dell’ applicazione dovevano rispettare una serie di requisiti imposti dalla situazione aziendale ovvero:

Oltretutto, dato lo scarso tempo per lo sviluppo dell’ applicazione, dovevano essere per me note abbastanza da potermi permettere di partire da un bon livello di conoscenza.

Non potendo essere affiancato da una persona esperta che potesse guidarmi nello sviluppo dell’ applicazione, avevo oltretutto bisogno di tecnologie che avessero alle spalle una grande community di utenti pronte a rispondere ai miei dubbi e domande, e che oltretutto avesse sviluppato delle librerie che io potessi utilizzare per non dovermi preoccupare di risolvere problemi che erano gia stati risolti da altri.

La scelta è quindi ricaduta su tutte tecnologie Open Source, all’ avanguardia e con ferventi communities: PostgreSQL, Node.js & Angular.js.

Queste tre tecnologie rappresentano i pilastri costituenti lo stack dell’ applicazione.

A queste sono state affiancate varie altre tecnologie per il Versioning dell’ applicazione(git), il TDD*(Mocha + Chai) il Deployment(Amazon AWS) ed il Package Management (npm, bower), e varie librerie che verranno in seguito descritte nel dettaglio._____________________________________________________________________*Scalabilità - Il termine scalabilità, nelle telecomunicazioni, nell'ingegneria del software, in

informatica e in altre discipline, si riferisce, in termini generali, alla capacità di un sistema di

"crescere" o diminuire di scala in funzione delle necessità e delle disponibilità. Un sistema

che gode di questa proprietà viene detto scalabile. - Wikipedia.

!14

• GRATUITO • MANUTENIBILE • SCALABILE • PERFORMANTE SU MACCHINE

ECONOMICHE


7.1 Database design

Il design del Database è stato portato avanti nel rispetto delle tre forme normali*. La volontà di costruire un applicazione di qualità è stata la forza motrice di questo progetto. Mi sono quindi impegnato per cercare il sistema più efficiente possibile nella gestione dei dati sul database.

Ho cercato di ridurre al minimo la ridondanza, sfruttando gli id e le foreign key, e di consentire un accesso ai dati semplice tramite una accurata naming convention delle tabelle, dei campi, delle sequenze e delle viste.

Il DBMS utilizzato è stato PostgreSQL. Le ragioni per cui è stato utilizzato sono: il fatto che faceva parte del curriculum dello scorso anno, ed ero quindi in grado di utilizzarlo con una certa padronanza, è gratuito, ha alle spalle una grande storia ed una fervente comunità di appassionati dell’ open source. I contro sono la sua complessità di configurazione per utenti inesperti, che è stata superata grazie alle conoscenze acquisite in classe, ed il suo client datato(PHPpgAdmin).

7.1.1 DIAGRAMMA ER

!15


7.1 Descrizione delle tecnologie Server-Side

Il backend dell’ applicazione è stato sviluppato con node.js. La scelta di questa tecnologia si è rivelata vincente per una serie di fattori, e principalmente perchè:

• Favorisce la modularità, si sposa perfettamente con l’ approccio scelto nell’ ideazione dell’ architettura software descritta precedentemente.

• Offre grandi vantaggi in termini di prestazioni grazie al suo Single Threaded - Non Blocking IO Model

• Ha una grande comunità di sviluppatori ed entusiasti, che si traduce nell’ esistenza di una grandissima mole di librerie e features pre implementate.

• Lo conoscevo avendolo studiato individualmente.

Pur garantendo ottimi vantaggi in termini di prestazioni può presentare dei problemi nel caso di connessioni simultanee al client data la sua gestione dello scope delle variabili.

Bisogna essere molto consapevoli di quello che si sta facendo quando si utilizzano queste tecnologie su questo tipo di progetti, perché un errore nella gestione di una variabile a questo livello potrebbe risultare nella spedizione di un ordine ad un indirizzo sbagliato.

Un altro aspetto di cui essere consci è la comprensione del modello Single Threaded-Non Blocking, che implica la conoscenza di diversi concetti che se non compresi a fondo, trasformerebbero istantaneamente i vantaggi che questo modello propone in gravi limiti nelle prestazioni e nella responsività dell’applicazione intesa come tempo di attesa percepito dall’utente a seguito di un’interazione.

Node.js non è un linguaggio orientato agli oggetti e questo comporta l’ utilizzo di paradigmi di sviluppo differenti. Per qualcuno potrebbe essere visto come uno svantaggio quando si parla di sviluppo e progettazione di applicazioni così complesse._____________________________________________________________________*Normalizzazione - procedimento volto all'eliminazione della ridondanza informativa e del

rischio di incoerenza dal database. Esistono vari livelli di normalizzazione (forme normali) che

certificano la qualità dello schema del database. *TDD - Test Driven Development, ita. sviluppo guidato dai test.

!16


7.2 Descrizione delle tecnologie Client Side

Per lo sviluppo della parte client sono state utilizzate numerose tecnologie, tutte open source.

Angular.js è il framework attorno al quale ruotano tutte le tecnologie utilizzate che sono:

La User Interface è stata sviluppata con in mente il modello Behaviour Driven (BDD).

Behaviour Driven Development significa “Programmazione guidata dal comportamento” e si traduce nel definire, tramite appositi framework, nel nostro caso Jasmine, il comportamento che si vuole che l’ applicazione abbia nel momento in cui l’ utente interagisce con essa.

Questo tipo di framework consentono quindi di emulare interazioni con il client e di definire quale deve essere la risposta attesa da questo.

Il concetto è simile al Test Driven Development, visto in precedenza, e si traduce nello sviluppare, per primi, dei moduli in cui verranno definiti i comportamenti attesi dall’applicazione a seguito di un interazione dell’ utente.

Questo approccio si usa per automatizzare i test della User Interface e per circoscrivere ed ottimizzare i moduli in modo tale da poter effettuare un pronto e chirurgico intervento nel momento in cui ci accorgessimo che l’ applicazione non risponde nel modo desiderato a seguito di un interazione con l’ utente.

TECNOLOGIA FUNZIONE

HTML5 + CSS3 Markup Language & Layout Design

Angular.UI + Bootstrap UI/UX Development

Jasmine Behaviour Driven Tests Framework per la User Interface

Font Awesome Icone e fonts dell’ applicazione

!17


I downsides che propone questo approccio sono nel tempo di sviluppo, che sicuramente aumenta, e negli ostacoli relativi al dover imparare la sintassi dei framework Behaviour Driven che, nel caso di Javascript, è diversa da quella standard.

Per queste ragioni non tutta l’ applicazione è stata sviluppata secondo questo paradigma, ma soltanto le parti aventi una maggiore complessità ed importanza come ad esempio il Checkout e la Registrazione.

Per le icone ed i font che compaiono sul sito è stata utilizzata una libreria grafica appartenente ad un progetto open source: Font Awesome.

www.fontawesome.com

La scelta di utilizzare Angular.js per lo sviluppo del client è stata dettata dalla necessità di sviluppare un applicazione fornita di schermate fortemente interattive ed animate, e dalla gestione e la validazione dell’ input dell’ utente.

Il tempo a mia disposizione mi ha obbligato ad utilizzare tecnologie che già conoscevo e quindi la scelta è ricaduta su questo framework, che avevo imparato ad utilizzare tramite corsi online ed il precedente tirocinio aziendale in Insiel s.p.a.

Angular.js lascia che sia il client a fare la maggior parte del lavoro quindi si può risparmiare sulle risorse hardware del server web che si limiterà ad inviare staticamente un unico file, index.html, e tutto il javascript necessario. Sarà poi il client a gestire il routing dell’applicazione web così come il contenuto delle pagine. L’ applicazione è stata sviluppata con il modello Single Page.*

Questo chiaramente con un prezzo che riguarda la retrocompatibilità con browser antecedenti ad IE8, le performance su macchine con hardware limitato e la Search Engine Optimization(SEO).

Questi problemi possono essere comunque risolti tramite la preparazione sul server di pagine apposite per i motori di ricerca e l’ implementazione di modernizer, libreria javascript per la retrocompatibilità.

!18

http://www.fontawesome.com


7.3 Versioning

Il sistema di versioning utilizzato è stato GIT.

La scelta è ricaduta su questo sistema perché è stato un argomento trattato durante il corso, è il sistema di versioning più diffuso ed in voga del momento e propone un ottimo modello per la gestione delle versioni dell’ applicazione.

In azienda non era presente alcun sistema di versioning, anzi, non sapevano nemmeno cosa fosse. Mi sono preso io la briga di spiegarglielo, sono stati molto contenti e mi hanno chiesto di installarne uno in azienda. Il server che mi hanno fornito per l’ installazione del sistema di versioning era un vecchio computer portatile chiamato da loro ironicamente “craptop”.

Ha funzionato per un po ma ad un certo punto si è spento definitivamente ed ha smesso di dare alcun segno di vita. Per fortuna giornalmente creavo back-up del progetto sul mio hard disk esterno. Divertente come nei bagni dell’ ufficio fosse appeso un quadro con scritto “Spero tu abbia fatto un back-up”. Sono ripartito quindi dall’ultima versione salvata ed ho smesso di utilizzare un sistema di versioning remoto ma lo usavo solo in locale, ed a fine giornata, dopo il “commit” dei cambiamenti su git copiavo la cartella sul mio hard disk.

_____________________________________________________________________

*Single Page Application - Con Single-page application (in italiano: applicazione su singola pagina) o in sigla SPA si intende una applicazione web o un sito web che può essere usato o consultato su

una singola pagina web con l'obiettivo di fornire una esperienza utente più fluida e simile alle

applicazioni Desktop dei sistemi operativi tradizionali. In un'applicazione su singola pagina tutto il

codice necessario (HTML, JavScript e CSS) è recuperato in un singolo caricamento della pagina o le

risorse appropriate sono caricate dinamicamente e aggiunte alla pagina quando necessario, di solito

in risposta ad azioni dell'utente. La pagina non si ricarica in nessun punto del processo, né lascia il

controllo in un'altra pagina, sebbene moderne tecnologie web (come la API pushState() di HTML5

può fornire la percezione e la navigabilità in pagine logiche separate nell'applicazione). L'interazione

con una applicazione a singola pagina spesso coinvolge una comunicazione dinamica con il web

server.

!19


DEPLOYMENT

Per quanto riguarda la scelta della piattaforma per il deployment è stato effettuato uno studio di mercato.

Sono stati comparati i costi ed i servizi offerti da vari servizi di hosting, principalmente:

Heroku, Azure e Amazon AWS.

Dallo studio si è evinto che Amazon AWS, pur avendo un costo mensile leggermente più alto della concorrenza, offre grandi vantaggi in termini di semplicità di configurazione del server, gestione della sicurezza,configurazione del Load Balancer e del DNS; tutti servizi assolutamente indispensabile che avrei dovuto altrimenti sviluppare/configurare personalmente. Oltretutto è stato uno degli argomenti trattati durante il corso e quindi possedevo già delle conoscenze di base che mi avrebbero consentito di essere più rapido nell’ apprendimento ed approfondimento dello strumento.

E’ stata quindi scelta questa piattaforma per i vantaggi che offriva in termini di tempo.

La tecnologia utilizzata per il deployment dell’ applicazione è Elastic Beanstalk, che è una piattaforma sviluppata da Amazon per il Deployment di applicazioni web che automatizza molto del lavoro di configurazione del server, mette a disposizione una CLI attraverso la quale si può gestire il versioning ed il deployment dell’applicazione e si occupa di gestire autonomamente la creazione di nuove macchine nel caso in cui il server arrivi a regime, configurando l’ apposito load balancer.

Il database è stato “deployato" tramite RDS (Relational Database Server) e la configurazione del DNS è avvenuta tramite Route 53.

AWS è uno strumento molto potente una volta che se ne comprendono le dinamiche, l’ unica pecca che mi sento di dover citare è la disorganizzazione e la complessità della documentazione, che molto spesso è priva di esempi per casi d’ uso tipici.

!20


SUMMARY DELLE PRINCIPALI TECNOLOGIE UTILIZZATE

Tecnology Pros Cons

•Grande libertà di configurazione

•Downtime di 2 ore all’ anno

•Grande platea di servizi offerti(S3, EB, EL, RDS, EC2)

•Altamente scalabile •Compatibile con tutte le

tecnologie utilizzate •Diffuso, conosciuto e

rispettato

•Learning curve lenta •Documentazione male

organizzata •Prezzi più alti della

concorrenza •Molti concetti proprietari

•Gratuito •Conosciuto ed affermato

•Learning curve lenta

•Gratuito •Conosciuto ed affermato •Solido ed affidabile

•Complicato nella configurazione se non si è esperti

•Client datato

•Gratuito •Grande community •Performance •Scalabilità •è Javascript server-side! •Tecnologia conosciuta

ed in via di diffusione

•Non è un linguaggio ad oggetti

•Rischioso se non si conoscono a fondo le caratteristiche del linguaggio ed il modello su cui si basa

•Gratuito •MVC •Alta granularità nei test •Tecnologia conosciuta e

diffusa •Framework molto

potente una volta imparato

•Learning curve molto lenta

•Non ottimizzato per SEO •Completely client reliant •Molti concetti proprietari

!

!

!

!

!

!21


Funzionalità sviluppate

In questa sezione verranno elencate e descritte alcune delle principali funzionalità sviluppate per la piattaforma e-commerce.

• Registrazione, login ed Autenticazione

• Login con i social

• Gestione Account Utente

• Carrello

• Check Out & Pagamenti

• Content Management System(CMS)

Registrazione, Login & Autenticazione

La funzionalità di registrazione e login è stata una delle prime ad essere sviliuppate, ed una delle più complesse, insieme al checkout.

Il sistema di autenticazione utilizzato è una Cookie-Based authentication. La motivazione della scelta di questo sistema di autenticazione è dato dalla relativa semplicità nella sua implementazione comparata alle garanzie che offre in termini di sicurezza, se correttamente implementato.

I dati inseriti nei form di login e registrazione sono validati tramite l’ utilizzo di espressioni regolari, come verrà descritto più avanti nella sezione dedicata alla sicurezza.

Login con i social

I social scelti per il login sono Facebook, Twitter, Linkedin e Google+ La scelta è ricaduta su questi poiché sono i più affermati social del momento.

L’ autenticazione avviene tramite collegamento alle API messe a disposizione da questi social network.

L’ email dell’ utente verrà salvata nella nostra base dati e gli saranno associati tutti i dati pubblici del profilo( immagine profilo, nome e cognome).

Successivamente, sarà data all’ utente la possibilità di scegliere una password in modo da non doversi collegare nuovamente tramite social network ma direttamente attraverso il sistema di login del nostro circuito tramite il suo indirizzo email.

!22


Gestione account utente

E’ stata sviluppata una sezione del sito dedicata alla gestione del profilo dell’utente con varie funzionalità come l’ aggiunta e la modifica di indirizzi di spedizione, il cambio password ed una sezione dedicata al monitoraggio dello stato degli ordini effettuati.

Content Management System(CMS)

Per la gestione del sito da parte degli amministratori è stato sviluppato un sito web apposito, hostato sullo stesso server tramite Virtual hosting. Consente, una volta effettuato il login con un account registrato come administrator, di aggiungere, modificare e cancellare i prodotti presenti all’ interno dell’e-commerce e monitorare e modificare lo stato degli ordini. Il sito web è accessibile all’ indirizzo www.cms.hydrofly.co.uk.

!23

Server Virtuale

hydrofly.co.uk cms.hydrofly.co.uk

vhost1 vhost2

Server

request response

Modello di re-indirizzamento delle richieste dell’utente verso il server corretto

http://hydrofly.co.uk



http://www.cms.hydrofly.co.uk



Carrello

Per questa feature è stata utilizzata una libreria di Angular.js(ngCart) che forniva un ottima base di partenza. E’ stata poi customizzata per il mio caso d’uso con funzionalità e template html sviluppati da me.

Per lo sviluppo della User Interface del carrello mi sono ispirato alla Shopping Bag di Apple.

Nel momento in cui un oggetto viene aggiunto al carrello, è presente un anteprima dell’immagine ed il nome dell’oggetto aggiunto.

Il template è dinamico e vengono mostrate fino ad un massimo di 5 anteprime.

Tramite l’ icona del carrello è possibile accedere ad una pagina dedicata al carrello in cui verranno mostrati tutti i prodotti aggiunti con i loro prezzi rispettivi, i costi di spedizione ed il prezzo totale.

La gestione dei prodotti nel carrello è operata utilizzando i cookies del browser.

!24


Checkout

La fase di Checkout rappresenta il culmine in cui tutti i sistemi di sicurezza attuati nel sito web devono convergere. I dati dell’utente devono essere validati, la connessione al server di pagamento deve avvenire tramite un canale sicuro e certificato e deve essere stata attuata una politica di gestione dei dati delle carte di credito. Queste problematiche verranno discusse nel dettaglio nella sezione Sicurezza.

E’ stata posta particolare attenzione sullo sviluppo della User Interface di questa parte del sito web. Essendo una fase molto delicata vogliamo che l’ utente si senta quanto più al sicuro possibile nell’inserire i suoi dati all’ interno del nostro sistema, e questo obbiettivo è stato raggiunto tramite lo sviluppo di un interfaccia che dia un’idea di professionalità e solidità.

Essa è stata sviluppata tramite un unico form dinamico a passaggi multipli che consente di effettuare la validazione dell’input dell’utente tramite step successivi.

Le fasi in cui si divide la compilazione del form di checkout per utenti non registrati sono: Profile(creazione del profilo utente per il monitoraggio della spedizione), Shipping(inserimento dell’indirizzo di spedizione), Card(inserimento dei dati di pagamento) e Review(panoramica dell’ordine e conferma).

Per gli utenti registrati che hanno effettuato il login il form si modifica viene saltata la parte di creazione del profilo e si passa direttamente alla scelta dell’indirizzo di spedizione o al suo inserimento nel caso in cui non se ne avesse gia indicato uno in fase di registrazione.

Per l’ esecuzione delle transazioni bancarie l’ applicazione si appoggia ad un Payment Gateway* di terze parti, Stripe**

Stripe si occupa di gestire la validazione delle carte di credito/debito per evitare frodi, si incarica di amministrare ed assicurare in toto i dati delle carte di credito degli utenti e fornire i dati per la generazione delle fatture a transazione avvenuta.

L’ utilizzo del software avviene tramite chiamate alla loro API.

!25

Checkout form per utenti non registrati


Pagamento

Le fasi in cui si dipana la richiesta di pagamento e la sua autorizzazione sono le seguenti:Dopo la compilazione e la validazione del form(che avviene in tempo reale), viene sbloccato il pulsante di conferma che effettuerà una chiamata POST all’ API di Stripe con i dati inseriti dall’utente in formato JSON.***Il passaggio allo step di review dell’ ordine è consentito soltanto se Stripe validerà la carta di credito e risponderà con un http status 200 e con un token cifrato, che rappresenterà la carta di credito e verrà utilizzato successivamente nel momento di conferma della fase di review per effettuare l’ addebito. In caso contrario l’ utente verrà subito notificato e gli verrà richiesto l’ inserimento di una una modalità di pagamento valida.

Per la validazione dell’input dei campi è stata utilizzata una libreria open source, Angular-Stripe, che contiene tutte le Regular Expressions(vedi sez. 8.2) necessarie e si attiva aggiungendo all’ input gli attributi di validazione desiderati, ed ex. cc-number nel caso del numero della carta di credito.

___________________________________________________________________________*Payment Gateway - Un Payment Gateway è un servizio di application service provider che si incarica di autorizzare il trasferimento di denaro per e-businesses e online retailers.**Stripe - Compagnia americana, operante in oltre 20 paesi, che consente a privati e business di accettare pagamenti su internet in maniera sicura. Stripe si focalizza nel provvedere tutte le misure di prevenzione delle frodi del caso e l’ infrastruttura di banking necessaria per operare sistemi di pagamento online. - Wikipedia***JSON - Javascript Object Notation

!26

Fase di inserimento dei dati di pagamento


Sicurezza

In un applicazione di questo tipo è di fondamentale importanza la sicurezza dei pagamenti, l’ input validation e la gestione dei dati degli utenti tramite accesso previa autenticazione.

I rischi principali da tenere in considerazione sono:

• SQL Injection

• Man In The Middle Attacks

SQL Injection ed Input Validation

SQL Injection è una tecnica di code injection, usata per attaccare applicazioni data-driven, con la quale vengono inseriti degli statement SQL malevoli all'interno di campi di input in modo che vengano eseguiti (es. per fare inviare il contenuto del database all'attaccante). L'SQL injection sfrutta le vulnerabilità di sicurezza del software di un'applicazione, ad esempio, quando l'input dell'utente non è correttamente filtrato da 'escape characters' contenuti negli statement SQL.

Per far fronte a questo problema è stata applicata una politica di input validation doppia su tutti i campi input del sito web.

Per validazione doppia si intende che i dati di input sono validati sia sul client che sul server, dopo il submit e prima dell’ inizio di qualsiasi operazione sugli stessi.

Questo per evitare che i controlli vengano bypassati tramite injection di javascript malevolo sul client.

!27

fig. 4


La validazione viene effettuata(sia sul client che sul server) tramite Regular Expressions(REGEX)*

Utilizzando Javascript come linguaggio di programmazione su tutto lo stack dell’ applicazione, le REGEX non hanno dovuto essere riscritte e questo ha portato un vantaggio in termini di tempo di sviluppo dell’ applicazione.

___________________________________________________________________________

fig.4 - Esempio di SQL Injection. *REGEX - Una espressione regolare (in lingua inglese regular expression o, in forma abbreviata, regexp, regex o RE) è una sequenza di simboli (quindi una stringa) che identifica un insieme di stringhe. Programmi diversi supportano notazioni diverse per esprimere le stesse espressioni regolari, pertanto non esiste una sintassi universale -Wikipedia.

!28

Regular Expression per il controllo sull’email

tentativo di SQL Injection durante il Login


Man In the Middle Attacks(MITMA)

Un MITMA è un attacco in cui qualcuno segretamente ritrasmette o altera la comunicazione tra due parti che credono di comunicare direttamente tra di loro.

Un esempio di MITMA è l’eavesdropping*, in cui l'attaccante crea connessioni indipendenti con le vittime e ritrasmette i messaggi per far credere loro che stiano comunicando direttamente tramite una connessione privata, mentre in realtà l'intera conversazione è controllata dall’attaccante.

Questo nel nostro caso si traduce con il pericolo che i dati della carta di credito dell’ utente vengano intercettati durante l’ operazione di pagamento, o che la password di un utente possa essere salvata durante le operazioni di login e registrazione.

Per gestire questa problematica bisogna assicurarsi che il canale di collegamento sia diretto, sicuro e crittografato e che il server sia in grado di certificare l’ autenticità della propria identità sulla rete.

Per ottenere questo risultato è stato utilizzato l’ 'HyperText Transfer Protocol over Secure Socket Layer (HTTPS).

Il protocollo di autenticazione utilizzato(TLS**) è unilaterale; è solo il server ad autenticarsi presso il client. Il client, cioè, conosce l'identità del server, ma non viceversa, il client rimane anonimo e non autenticato sul server.

!29

fig. 5


Questo risultato può essere raggiunto tramite la certificazione del server presso una Certification Authority(CA)***, e l’ invio del certificato al browser nel momento della connessione.

I siti che intendono ingannare l'utente non possono utilizzare un certificato del sito che vogliono impersonare perché non hanno la possibilità di cifrare in modo valido il certificato, che include l'indirizzo, in modo tale che risulti valido alla destinazione. Solo le CA possono generare certificati validi con un'URL incorporata in modo che il confronto fra l'URL apparente e quella contenuta nel certificato possa fornire un metodo certo per l'identificazione del sito.

Al momento della connessione al server viene verificato il protocollo di connessione utilizzato e tutte le connessioni non sicure(non https) vengono re-indirizzate ed avviene l’ invio del certificato al browser che ne potrà verificare la validità.

___________________________________________________________________________fig.6 - La figura rappresenta la catena di certificazione del sito web. Geo Trust Global è la Certification Authority che fornisce a RapidSSL la possibilità di emettere il certificato per www.hydrofly.co.uk.fig.7 - Icona del lucchetto di HTTPS. Notifica che la connessione al sito è privata.*Eavesdropping - Si definisce in questo modo qualsiasi attività di intercettazione dell’informazione che violi il consenso delle parti interessate.**TLS - Transport Layer Security (TLS) e il suo predecessore Secure Sockets Layer (SSL), sono dei protocolli crittografici usati nel campo delle telecomunicazioni e dell'informatica che permettono una comunicazione sicura dal sorgente al destinatario (end-to-end) su reti TCP/IP (come ad esempio Internet) fornendo autenticazione, integrità dei dati e cifratura operando al di sopra del livello di trasporto. - Wikipedia.***Certification Authority - In crittografia, una Certificate Authority o Certification Authority (CA), letteralmente Autorità Certificativa, è un ente di terza parte (trusted third party), pubblico o privato, abilitato a rilasciare un certificato digitale tramite procedura di certificazione che segue standard internazionali e conforme alla normativa europea e nazionale in materia. - Wikipedia.

!30

fig. 6

fig. 7



Sicurezza nei pagamenti

Come detto nel capitolo riguardante lo sviluppo del checkout, durante la fase di pagamento devono essere applicate tutte le misure di sicurezza sopra descritte e bisogna attuare una politica di gestione dei dati delle carte di credito.

Per risolvere le problematiche relative allo storage di questo tipo di dati ho scelto di utilizzare un sistema che, invece di fornire soluzioni con cui far fronte al problema, lo elimini completamente.

Da qui la scelta di utilizzare Stripe come Payment Gateway.

Stripe si incarica di effettuare l’ operazione bancaria da noi designata tramite chiamata alla loro API ospitata su server sicuro e restituirci il risultato della transazione.

Per poter effettuare richieste al loro server è necessario che il server dal quale esse provengono sia certificato da una Certification Authority e che la connessione avvenga tramite protocollo HTTPS.

Grazie a questo approccio non c’è bisogno di conservare nel database della nostra applicazione i dati delle carte di credito degli utenti.

SOMMARIO DELLE MISURE DI SICUREZZA ATTUATE

PROBLEMA SOLUZIONE

SQL Injection Input Validation via Regular Expressions

Frode nei pagamenti & Gestione dati carte di credito

Stripe

MITMA HTTPS

Authentication Cookie Based Authentication

!31


RISULTATI CONSEGUITI

Alla fine del periodo di tirocinio sono riuscito a consegnare un prodotto finito e funzionante e pubblicato su www.hydrofly.co.uk

Il progetto è stato portato a termine con successo ed ho ricevuto un riconoscimento da parte del mio tutor che si è complimentato per il modo in cui ho portato avanti il lavoro, e mi ha chiesto di rimanere in contatto con lui per completarne lo sviluppo una volta che l’ Hydrofly entrerà in produzione.

SVILUPPI FUTURI

Il sito web è da completare con immagini adeguate e l’ aggiunta di contenuti per la descrizione del prodotto e del progetto.

In futuro andrebbe sicuramente rinforzato il meccanismo di autenticazione dell’API, con l’ implementazione di una modalità di autenticazione Token-Based.

Un altro aspetto da migliorare è sicuramente l’ aspetto grafico del contenuto delle email di fatturazione e registrazione, che ora sono abbastanza spartane.

RINGRAZIAMENTI

La realizzazione di questo progetto non sarebbe stata possibile senza l’ aiuto di Steve Maraspin, che mi ha fornito molti spunti e consigli ed è stato sempre molto disponibile e pronto a rispondere alle mie domande; e di mio Padre, programmatore Cobol da oltre 20 anni, che mi ha guidato nella realizzazione del modello Entity-Relationship del database e nel suo sviluppo.

Gran parte del merito va a loro e quindi li voglio ringraziare sentitamente.

Mi sento di poter dire di aver imparato molto da quest’esperienza che mi ha avvicinato molto alla comprensione di cosa vuol dire essere un professionista in questo settore.

Voglio ringraziare sentitamente anche la fondazione, che mi ha dato questa incredibile opportunità grazie alla quale mi sento di essere cresciuto molto, sia a livello personale che professionale.

Grazie mille.

!32


Tesina ITS final

Documents

Transcript of Tesina ITS final