redroundrobin / swe-api Goto Github PK

Basandosi su https://api.docs.redroundrobin.site/

• /devices/cmdEnabled --> /devices?cmdEnabled={true/false} (da fare come request param)
• /devices/{deviceId}/sensors/cmdEnabled --> /devices/{deviceId}/sensors?cmdEnabled={true/false} (idem)

Invio dei comandi

• /gateways/command.. --> /sensors/{sensorId} [PUT]
• /gateways/config/{gatewayId} --> /gateways/{gatewayId} (body differente in cui abbiamo reconfig=true)

Descrizione del bug
Se tento di aggiungere un utente con la stessa email, mi da errore 500

Modifica da fare
Deve essere visibile l'errore effettivo alla sua aggiunta.

in generale sono da utilizzare questi errori:

• 400 ->la richiesta(aka la parte in body) non e' conforme;
• 401 ->login non autorizzato OPPURE il token non esiste/e' errato;
• 403 ->lo user e' autenticato e la richiesta e' valida ma NON HA ACCESSO alla risorsa;
• 404 ->lo user e' autenticato, la richiesta e' valida, e puo' accedere alla risorsa ma la risorsa in questione NON ESISTE;
• 409 ->se esiste un qualche tipo di conflitto in db relativo alla richiesta;
• 419 ->il token e' presente ma e' scaduto
• 503 ->telegram non risponde

se ora vengono generati altri errori oltre a quelli elencati sopra scriveteli nella issue che vediamo come gestirli

Creazione funzione per il check dell'username di Telegram ed eventuale salvataggio della chat id. Lo scheletro della funzione è già presente nella repo nel branch feature/aggiuntaPostgreSpring.
La funzione deve ritornare un int non una String

CODICI:
0 se l'username di telegram non è presente nel Database
1 se l'username di Telegram è presente e il chatId è vuoto (Bisogna quindi inserirlo)
2 se L'username di Telegram è presente e c'è già la chatId

Descrizione del bug
Un admin non può modificare un ente dalla webapp.

Modifica da fare
Un admin deve poter modificare un ente qualunque nelle sue due informazioni (nome e luogo).

Descrizione del bug
Se un utente o moderatore ha le seguenti caratteristiche:

• type: 0, 1
• deleted: 0
• entityId: 0/null
  Può comunque ricevere un token di accesso, anche se viene bloccato nel sito con una richiesta 403.
  Tale modifica può essere attuata solo se chi amministra il DB va a settargli appositamente ID=0/null.

RA-F-60

Modifica da fare
Secondo voi serve trattarla come cosa o è sufficiente l'errore di questo genere?

I log conterranno:

• il timestamp (time)
• l'id utente che ha fatto l'azione (user_id)
• l'ip di chi ha fatto l'azione
• l'azione effettuata (operation) e le informazioni relative (data) :

Le dipendenze circolari identificate dopo la riunione riguardano:

• models
• service

I models utilizzano necessariamente il collegamento bidirezionale per mantenere la struttura del database di Postgresql e timescaledb.

Non è richiesto nessun tipo di fix, la funzionalità è prevista da Spring.

I services, invece, fanno uso di altri XxxxServices in modo improprio dal momento che sarebbe sufficiente implementare le repository di Spring, nelle quali sono presenti i metodi necessari.

Soluzione: cambiare gli XxxxxServices con i Repos al fine di rimuovere le dipendenze circolari. Le uniche dipendenze saranno quindi (ad esempio):

• UserServices --> UserRepository | EntityRepository | ecc.

Descrizione del bug
La ricezione del codice di auteticazione tramite Telegram non funziona

Modifica da fare
Potrebbe essere un problema delle API

Tipo di richiesta (TYPE)
GET

Permessi
USER, MOD, ADMIN

INPUT
Verrà inoltrata una richiesta per ritornare delle stats specifiche che verranno mostrate nella dashboard. In particolare, in riferimento all'AdR, UC 2 - Visualizzazione dashboard.

• utenti attivi nel sistema (ossia utenti che hanno eseguito il login guardando le logs negli ultimi 30 minuti);
• utenti attivi appartenenti al proprio ente (come sopra);
• numero totale di utenti nel sistema;
• numero totale di utenti nel proprio ente;
• dispositivi censiti nel sistema;
• dispositivi censiti nel proprio ente;
• numero totale di enti;

OUTPUT
Deve essere mostrato un numero intero che va da 0 a N per ogni richiesta.
Può essere gestita singolarmente o anche in modo univoco (una richiesta generica e un intero array di risposta).

Note aggiuntive
//

Tipo di richiesta (TYPE)
GET

Permessi
USER/MOD

INPUT
niente

OUTPUT
403 ma dovrebbe tornare la lista di gateways che puo' vedere solo il mod

Note aggiuntive
IMPORTANTE

• Gestire le richieste HTTP dal sito con un pattern per gli url
• Provare a integrare spring

API:

NB: il token di autenticazione viene conservato fino alla fine della sessione

• ####Autenticazione
  /* Richiede: username e password
  
  */ Ritorna: un oggetto "utente" ed il relativo token sse il 2FA non e' attivo
  

  • Autenticazione semplice
    • Metodo: POST
    • Header: .JSON
    • URI: /auth
    • Body: {
      
        username: "usr",
      
        password: "psw"
      
       }
    • Risposta: .JSON :: {
      
        token: "",
      
        utente: {}
      
       }

  /* Richiede: username e password
  
  * Ritorna: un oggetto "utente" ed una notifica che e' richiesta
  
  */ l'autenticazione tramite telegram

  • Autenticazione-telegram "2FA"

    • Metodo: POST
    • Header: .JSON
    • URI: /auth
    • Body: {
      
        username: "usr",
      
        password: "psw"
      
       }
    • Risposta: .JSON :: {
      
        telegram: true,
      
        utente: {}
      
       }

  /* Richiede: username di telegram e il token inserito dall'utente
  
  */ Ritorna: un oggetto "utente" ed il relativo token

  • Autenticazione telegram-"token"
    • Metodo: POST
    • Header: .JSON
    • URI: /auth/telegram
    • Body: {
      
        username: "usr",
      
        token-telegram:""
      
       }
    • Risposta: .JSON :: {
      
        token: "",
      
        utente: {}
      
       }

• ####Gestione Utente
  /* Richiede: il token utente
  
  */ Ritorna: un oggetto "utente"
  

  • Dettagli utente
    • Metodo: GET
    • Header: token: ""
    • URI: /users
    • Body: //
    • Risposta: .JSON :: {
      
        utente: {}
      
       }

  /* Richiede: il token utente e un oggetto utente ben formato
  
  * che contiene una configurazione valida per l'utente
  
  */ Ritorna:
  

  • Configurazione utente
    • Metodo: POST
    • Header: token: ""
    • URI: /users/{userId}/edit
    • Body: .JSON :: {
      
        utente: {}
      
       }
    • Risposta: //

  /* Richiede: il token utente e un oggetto utente ben formato
  
  * che contiene una configurazione valida per un nuovo l'utente
  
  */ Ritorna:
  

  • Configurazione utente
    • Metodo: POST
    • Header: token: ""
    • URI: /users/create
    • Body: .JSON :: {
      
        utente: {}
      
       }
    • Risposta: //

• #####Gestione Ente
  /* Richiede: il token utente
  
  */ Ritorna: un oggetto "ente"
  

  • Dettagli utente
    • Metodo: GET
    • Header: token: ""
    • URI: /istitutions
    • Body: //
    • Risposta: .JSON :: {
      
        ente: {}
      
       }

  /* Richiede: il token utente e un oggetto ente ben formato
  
  * che contiene una configurazione valida per l'ente
  
  */ Ritorna:
  

  • Configurazione utente
    • Metodo: POST
    • Header: token: ""
    • URI: /institutions/{enteId}/edit
    • Body: .JSON :: {
      
        ente: {}
      
       }
    • Risposta: //

  /* Richiede: il token utente e un oggetto utente ben formato
  
  * che contiene una configurazione valida per un nuovo l'ente
  
  */ Ritorna:
  

  • Configurazione utente
    • Metodo: POST
    • Header: token: ""
    • URI: /institutions/create
    • Body: .JSON :: {
      
        utente: {}
      
       }
    • Risposta: //

  //todo cambio config utente

/utente autenticato/

• #####Dispositivi

  /Richiede: il token && l'id di un device
  Ritorna: un .JSON contenente lista degli id dei sensori connessi al device richiesto + info del device
  &&
  il numero dei sensori connessi al device/

  • Metodo: GET
  • Header: token
  • URI: /devices/deviceId
  • Body: //
  • Risposta: .JSON :: {"deviceId": "val",
    "timestamp": "val",
    "sensorsList": [{
    "sensorId": "val",
    ]}
    ...
    "deviceId": "val",
    "timestamp": "val",
    "sensorsList": [{
    "sensorId": "val"
    ]}
    "sensorsNumber": "numberOfSensors"
    }

• #####Sensori

  /Richiede: il token && l'id di un device && l'id di un sensore connesso al device
  Ritorna: un .JSON contenente le informazioni del sensore/

  • Metodo: GET
  • Header: token
  • URI: /devices/{deviceId}/{sensorId}
  • Body: //
  • Risposta: .JSON :: {
    "sensorId": "val",
    "timestamp": "val",
    "value": "val"
    }

• ####Gateway- modifica configurazione

  /Richiede: il token && l'id di un gateway
  Ritorna: una stringa di testo che dice se è avvenuta la modifica o meno/

  • Metodo: POST
  • Header: token
  • URI: gateways/{gatewayId}/update
  • Body: {
    gatewayId: "val",
    token: "token"
    }
  • Risposta: stringa di testo

• ####Gateway-richiesta configurazione

  /Richiede: il token && l'id di un gateway
  Ritorna: un .JSON contenente la configurazione corrente del gateway richiesto/

  • Metodo: GET
  • Header: token
  • URI: gateways/{gatewayId}
  • Risposta: .JSON

• #####Gateway/Topic
  /* Richiede: il token utente
  
  */ Ritorna: un array di oggetti topic

  • Lista topics
    • Metodo: GET
    • Header: token: ""
    • URI: /topics
    • Body: //
    • Risposta: .JSON :: {[
      
        {
      
         topicId: "",
      
         info: [...]
      
        },
      
        ...
      
       ]}

  /* Richiede: il token utente e l'id del topic
  */ Ritorna: un oggetto topic

  • Dettagli topic
    • Metodo: GET
    • Header: token: ""
    • URI: /topics/{topicId}
    • Body: //
    • Risposta: .JSON :: {
      
        topicId: "",
      
        info: [...],
      
        listaDispositivi: [...]
      
       }

Descrizione del bug
I nuovi ID di qualunque entità nel DB partono da 76

Modifica da fare
Gli ID dovrebbero andare avanti in modo incrementale e non dovrebbero partire da 76.

Descrizione del bug
Data ora invio ultima configurazione non viene aggiornato nel DB.

Modifica da fare
Ogni volta che si riceve un poke di invio nuova configurazione a un determinato gateway, va fatta una query per aggiornare a NOW() l'ultimo invio.

Test metodi telegram

• Login senza telegram_name a db
• Login con solo telegram_name a db
• Login con telegram_name e telegram_chat a db
• Login con telegram_name e telegram_chat a db ma utente disabilitato
• Testare /status (sia in modo funzionale che automatico)

Test metodi webapp:

• getUserDevices
• getUserEntity
• createUser
• editUser

Limit e sensor. Ci sono problemi.

Il sensore dovrebbe mostrare solamente una variazione sull'asse del 30 e non del 20. Questo implica che la richiesta al DB è fatta male. Va ricontrollata, perché i dati non sono conformi e non rimangono intorno alle registrazioni reali.

Obiettivi

• Auto-apprendimento API REST e loro funzionamento
• Capire i design pattern utili alle API
• Trovare tutte le funzionalità da implementare sia per il bot di telegram che per la webapp, basandosi sui casi d'uso.

Guardare issue #53

• Login normale (operation: auth.login, data: webapp)
• Login tfa richiesto (operation: auth.login, data: sent tfa code)
• Login telegram (operation: auth.login, data: telegram")
• Modifica delle impostazioni (operation: user.settings_edit, data: )
• Modifica della password (operation: user.password_edit , data: )
• Ricezione codice telegram (operation: auth.login , data: tfa confirmed)
• Creazione utente (operation: user.add, data: {ID utente creato})
• Modifica utente (operation: user.edit , data: {ID utente modificato})
• Disattivazione utente (operation: user.delete , data: {ID utente disattivato})
• Reset Password (operation: user.password_reset , data: {ID utente a cui è stata resettata la password})
• Creazione alert (operation: alert.add, data: {ID alert creato})
• Modifica alert (operation: alert.edit , data: {ID alert modificato})
• Rimozione alert (operation: alert.delete , data: ["alerts with sensorId = {sensorId}", {ID alert rimosso (rimozione logica)}])
• Creazione ente (operation: entity.add, data: {ID ente creato})
• Modifica ente (operation: entity.edit , data: {ID ente modificato})
• Disattivazione ente , data: entity.delete , data: {ID ente disattivato (rimozione logica a cascata per users e alerts)})
• Aggiunta dispositivo (operation: device.add, data: {ID gateway e ID reale dispositivo aggiunto})
• Modifica dispositivo (operation: device.edit, data: {ID gateway e ID reale dispositivo modificato})
• Rimozione dispositivo (operation: device.delete, data: {ID gateway e ID reale dispositivo rimosso (rimozione fisica)})
• Modifica sensore ente (operation: entity.assign_sensor, data: {ID ente a cui è stato aggiunto o rimosso il sensore})
• Invio input telegram (operation: sensor.input, data: {ID sensore logico})
• Invio Configurazione gateway (operation: gateway.reconfig, data: {gateway a cui è stata inviata la configurazione})

Tipo di richiesta (TYPE)
GET

Permessi
USER, MOD, ADMIN

INPUT
Richiesta Coffee/ vuota

OUTPUT
Risposta in protocollo http 418

Note aggiuntive
//

Descrizione del bug
Quando si rimuove un dispositivo, gli alert attivi e gli alert disabilitati per quel dispositivo non vengono rimossi, causando alterazione delle tabelle del DB.

Modifica da fare
Il sistema deve rimuovere automaticamente gli alert attivi di un dispositivo non più censito.

In kafka DB, se un dispositivo viene eliminato, i suoi sensori devono essere eliminati.
@Maxelweb --> modifico KafkaDB

Tipo di richiesta (TYPE)
consumatore Kafka

Permessi
USER/MOD/ADMIN

INPUT
Le API devono mandare a Telegram il messaggio contenente l'alert. Il messaggio che viene ricevuto dal topic di kafka contiene il sensore, il dispositivo, una lista di chat id, il valore attuale del sensore e la soglia che è stata superata

OUTPUT

Quello che dovrete inoltrare a Telegram sarà il tipo di richiesta (req_type), l'id del dispositivo (device_id), l'id del sensore (sensor_id), sensor_value, threshold, value_type e chat id;
Da valutare se mandare n richieste (quindi un messaggio per ogni chat id ricevuta) o una lista di chat id in un singolo messaggio

Note aggiuntive
Questo implica che anche quando viene mandato il codice di autenticazione sarà necessario aggiungere un campo req_type al messaggio inviato per poter discriminare i vari tipi di richiesta

Per testare è necessario seguire i seguenti passi:

1. Installare Docker
2. Clonare le repo swe-gateway (develop), swe-api (springApi) e swe-kafka-db (develop) con GitKraken o GitHubDesktop
3. entrare nella cartella kafka della repo swe-kafka-db ed eseguire da terminale docker-compose up -d
4. Aprire il browser ed andare all'URL localhost:9099 per accedere a Kafka manager e da li creare un cluster dove il nome lo potete scegliere voi mentre nel secondo campo dovete scrivere "zookeeper:2181", tutto il resto va bene .
5. Aprire i progetti swe-gateway (cartella gateway) e swe-api (cartella apirest) con IntelliJ
6. Eseguire dal progetto gateway (in ordine) UsDevice1, SgDevice2 e DeDevice3 poi UsGateway1, SgGateway2 e DeGateway3 (ora avrete 3 gateway attivi che sparano dati nei rispettivi topic di Kafka)
7. Eseguire dal progetto apirest ApirestApplication e poi ora potete provare le richieste facendo nel browser, ad esempio localhost:8080/topic/US-GATEWAY-1 oppure localhost:8080/devices

Vanno scritte le seguenti strutture dati:

• Devices

  • String message
  • Devices()
  • String setMessage(List<JsonObject> devices)

• Device

  • final String ID
  • String message
  • Device(String id)
  • String setMessage(JsonObject device)

• Sensor

  • final String deviceID
  • final String sensorID
  • Sensor(String deviceId, String sensorId)
  • String setMessage(JsonObject sensor)

Vanno scritti i seguenti metodi nella classe DataFetch

• List<JsonObject> getDevices()
• JsonObject getDevice(String deviceId)
• JsonObject getSensor(String deviceId, String sensorId)

Le funzioni fano il fetch dei dati da tutti i topic (la lista dei topic è presente nella classe DataFetch come membro final)

Per fare le funzioni si consiglia di usare la funzione DataFetch.getForTopics(String[] topics) (che prende un messaggio per ogni topic specificato ed inserisce i suoi elementi in una lista che poi viene ritornata). Potrebbe essere una buona idea prendere quindi la lista di JsonObject ritornata (nella forma [{DeviceId, Timestamp , sensori:[{SensorId, Timestamp, Valore}, {...altro sensore...}, ...]})

NB: Ogni JsonObject dovrebbe rappresentare un dispositivo con i suoi sensori in teoria