@@ -15,7 +15,7 @@ L’accesso all’intero sistema è controllato tramite autenticazione con OAUTH
# 1. Specifiche funzionali
## 1.1. Controllo tramite sensori ed attuatori
Il sistema nella LAN è costituito da una BeagleBone (BB), con attuatori e led; e un Arduino, cui è collegato un sensore di luminosità.
Il sistema nella LAN è costituito da una BeagleBone (BB), con attuatori e led; e un Arduino, a cui è collegato un sensore di luminosità.
Gli attuatori simulano gli interruttori e i sensori di movimento.
...
...
@@ -37,7 +37,7 @@ I servizi in Cloud consistono nei seguenti servizi:
Questi servizi sono stati resi sicuri con l'implementazione di HTTPS e WSS usando dei certificati self-signed.
# 2. Analisi <!-- nelle slide l'ho un po' ristrutturato>
# 2. Analisi <!-- nelle slide l'ho un po' ristrutturato -->
## 2.1. Installazione del sistema in reti private
L'installazione del sistema avviene senza configurazioni particolari: utilizzando mosquitto con la configurazione da noi impostata, è sufficiente collegare il sistema alla rete internet per avere le funzionalità richieste disponibili.
## 2.2. Accessibilità da rete pubblica e da rete privata
...
...
@@ -108,13 +108,25 @@ Il Webserver fornisce la webapp. L'utente, navigando nella webapp, può controll
## 4.2. Distribuzione delle funzionalità tra i moduli, attività e loro interazione
<!-- (ognuno si scriva i suoi 2)
(cosa fa ogni modulo) -->
### 4.2.1. Webserver e Webapp
### 4.2.1. Webserver e Webapp
Il Webserver, implementato come server HTTPS concorrente, fornisce la Webapp al client grazie all'uso di API REST.
La Webapp può comunicare con il Message Broker grazie al protocollo MQTT, con il server di autenticazione (Keycloak) con l'utilizzo di Token JWT e con il DM tramite API REST.
La Webapp può comunicare con il Message Broker grazie al protocollo MQTT, con il server di autenticazione (Keycloak) <!-- con l'utilizzo di Token JWT --> e con il DM tramite API REST.
### 4.2.2. Keycloak
<!--DA FARE elisa-->
### 4.2.3. Domain Manager <!-- non sono certa che operi in cloud. Meglio omettere>
L'autenticazione è gestita con Keycloak. Per ottenere il "grant" di accesso è stata utilizzata la sequenza "Authorization Grant con PKCE".
La pagina iniziale si trova all'url https://localhost:3000/
Il Webserver fornisce al browser una pagina vuota contentente solo un link (non visibile all'utente). Tramite javascript, si ridirige la pagina al link specificato, ovvero viene fatta una richiesta GET all'authorization server. Nell'URI della richiesta sono presenti i seguenti query parameters: response_type, code_challenge, code_challenge_method, client_id, redirect_uri, scope, nonce, response_mode, state.
L'utente inserisce username e password.
Se l'autenticazione ha successo, l'authorization server risponde con un authcode e un URI (https://localhost:3000/secured).
Il browser mostra quindi la pagina contenente tutti i domini dell'utente che ha effettuato il login e provvede a inviare una richiesta POST per ottenere il token.
Nel body della richiesta sono specificati grant_type, client_id, code_verifier, code, redirect_uri.
Periodicamente, prima che scada il token e se l'utente è ancora loggato, viene fatta la richiesta di un nuovo token utilizzando il refresh token.
Inoltre, ogni volta che l'utente effettua un'operazione che richiede l'uti
### 4.2.3. Domain Manager <!-- non sono certa che operi in cloud. Meglio omettere -->
Il DM è un microservizio <!-- che opera in Cloud, -->con funzionalità da server REST ed interagisce con il DB dell'intero sistema.
Si occupa di soddisfare le richieste HTTPS provenienti dalla Webapp, controllandone la validità e la consistenza col DB e inoltrarle al CAM richiamando degli URI esposti da quest'ultimo.
Dopo aver verificato l'autorizzazione tramite il Token fornito da Keycloak, il DM interagisce con il DB ed effettua la chiamata al CAM.
...
...
@@ -135,7 +147,13 @@ La persistenza è garantita grazie all'uso di tre file che vengono aggiornati in
- Antifurto
<!--DA FARE elisa: qui mettiamo una descrizione breve del microservizio-->
Permette la gestione di un sistema di antifurto. Un pulsante consente di attivare / disattivare l'antifurto. I sensori di movimento sono simulati mediante pulsanti sulla BB. A ciascun sensore di movimento corrisponde un valore delta.
In caso di antifurto impostato, l'allarme scatta nel momento in cui si supera un certo valore soglia. Questo meccanismo è stato pensato per cercare di evitare falsi allarmi.
Due led consentono all'utente di conoscere lo stato dell'antifurto, ovvero se esso è impostato e se sta suonando.
L'intero sistema è configurabile dall'utente: è possibile cambiare il pulsante di accensione/spegnimento dell'antifurto, la soglia oltre la quale scatta l'allarme e i due led. E' anche possibile aggiungere sensori di movimento.
La persistenza è realizzata mediante la scrittura e la lettura di file JSON. Si mantiene traccia dello stato dell'antifurto, del valore raggiunto, del momento in cui è scattato l'allarme, della soglia, dei sensori di movimento presenti (con i corrispondenti valori delta), dell'interruttore di accensione e spegnimento dell'antifurto e dei due led.
### 4.2.5. Arduino
Questo componente della LAN scrive sul broker Mosquitto della BB i valori del sensore di luminosità, usato dal microservizio delle luci per decidere se l'ambiente è abbastanza buio da dover accendere le luci nel caso in cui il suo sensore di movimento invii un messaggio.
### 4.2.6. Cloud App Manager
...
...
@@ -211,7 +229,35 @@ Sono inoltre presenti 2 classi di utilità: UserChangeSync ed Helper.
La prima permette all'utente di modificare lo scenario attivo dalla Webapp e quindi di avere un vero impatto su quale scenario stia venendo usato.
La seconda espone dei metodi che vengono usati da più classi.
<!--DA FARE elisa la tua parte spiegata nel dettaglio-->
- Antifurto
Il microservizio Antifurto si compone di 9 classi: Antifurto, Automa, Esecutore, Helper, MyQueue, Pair, Publisher, SubscribeCallback, Timer.
La classe principale è Antifurto. Essa si occupa di far partire il microservizio ed espone alle altre classi:
- un metodo per pubblicare messaggi MQTT,
- un metodo per sottoscrivere un ulteriore topic,
- un metodo per effettuare l'unsubscribe di un topic.
Sono inoltre presenti getter e setter degli IN e OUT in uso dal microservizio.
L'automa che rappresenta il microservizio Antifurto è scritto nel file automa.json. Basandosi su questo file, la classe Automa gestisce lo stato dell'antifurto.
La classe generica MyQueue implementa una coda. Il tipo degli oggetti in coda verrà specificato nel momento in cui si crea un'istanza della classe. La gestione dell'intero sistema si basa su due code: una (codaMsg) contenente i messaggi MQTT da pubblicare e una (codaVal) contenente i valori (positivi o negativi) da sommare a una variabile cumulativa mantenuta e aggiornata da Esecutore.
Gli oggetti nella codaMsg sono istanze della classe Pair. Ogni istanza di Pair è caratterizzata dal topic su cui si vuole pubblicare il messaggio e dal testo del messaggio stesso.
La classe Publisher estrae, uno alla volta, gli oggetti presenti nella codaMsg ed effettua le pubblicazioni su MQTT.
La classe Esecutore gestisce effettivamente il sistema di antifurto. Ha una variabile cumulativa che viene incrementata e decrementata (solo in caso di antifurto impostato) in base ai valori che si estraggono, uno per volta, dalla codaVal. Questa variabile è confrontata continuamente con il valore soglia: se il suo valore supera la soglia, scatta l'allarme; viceversa, se il suo valore scende sotto la soglia, l'allarme smette di suonare. E' inoltre presente un tempo massimo di allarme: l'allarme non suonerà mai per un periodo superiore a questo tempo.
In caso di antifurto impostato la classe Timer aggiunge periodicamente un valore negativo alla coda dei valori. Così facendo, il valore della variabile cumulativa della classe Esecutore verrà man mano decrementato a meno di rilevazioni di movimento da parte dei sensori. Questo permette, assime al tempo massimo di allarme, di evitare che l'allarme suoni fino a quando l'utente non disattiva l'antifurto.
La classe SubscribeCallback gestisce la perdita di connessione con il broker (tentando la riconnessione) e l'arrivo dei messaggi MQTT (in base al messaggio arrivato e al topic su cui è stato pubblicato, viene chiamato un opportuno metodo di questa classe).
La classe Helper espone metodi per la scrittura e la lettura di file.
