API – Application Programming Interface – Prima Parte

A questo punto passiamo alla parte di sviluppo e cerchiamo di simulare il meccanismo di autenticazione così come descritto nel diagramma di sequenza. Accendendo alla cartella del primo progetto potremmo aggiungere un file dal nome app_auth_1.js. Il codice da inserire sarà il seguente.

const express = require('express');
const jwt = require('jsonwebtoken');

const app = express();
const port = 3000;

const SECRET_KEY = '348934893L_@@@@ewe'; // Chiave segreta per la firma e la verifica del token

// Middleware per la verifica del token
const verifyToken = (req, res, next) => {
    const authHeader = req.headers['authorization'];
    const token = authHeader && authHeader.split(' ')[1];

    if (!token) return res.sendStatus(401); // Non autorizzato

    try {
        // Verifica il token utilizzando la chiave segreta
        const decoded = jwt.verify(token, SECRET_KEY);
        req.user = decoded;
        next();
    } catch (error) {
        return res.sendStatus(403); // Vietato
    }
};

app.use(verifyToken);

app.get('/occupazione-suolo', (req, res) => {
    // Logica dell'endpoint
    res.json({ message: 'Richiesta di occupazione del suolo ricevuta!' });
});

app.listen(port, () => {
    console.log(`Server in ascolto su http://localhost:${port}`);
});

Per quanto concerne la spiegazione del codice appena scritto, nelle prime due righe vengono importati i moduli Express e Jsonwebtoken. Come al solito se non li avete, utilizzate l’istruzione “npm install jsonwebtoken” come eseguito precedentemente nel primo esempio per il modulo Express. Le installazioni andranno eseguite da riga di comando.

Nella riga quattro viene creato un nuovo server Express, mentre nella riga cinque viene assegnata alla costante “port” il valore 3000. Questa sarà, la porta di ascolto del server NodeJS.

Nella riga sette alla costante “SECRET_KEY” viene assegnato un valore. Questa chiave segreta statica viene definita per firmare e verificare i token JWT. Questa chiave dovrebbe essere mantenuta segreta e per nessun motivo pubblicata. E’ ovvio che in produzione, in un contesto reale, non può essere presente una soluzione del genere con la gestione di una chiave segreta statica, ma qui lo facciamo solo a titolo di esempio.

Nelle righe dalla dieci alla ventiquattro viene estratto il token dall’header “authorization” della richiesta. Se in questo, non è presente nessun token, viene restituito un messaggio di errore 401 (Non autorizzato). Se c’è un token si procede con la verifica con la decodifica utilizzando una chiave segreta. Se tale operazione va a buon fine, allora, si “allegano” i dati decodificati a req.user e si passa alla route successiva. Se l’operazione di verifica non va a buon fine allora il sistema restituisce un errore 403 (Vietato).

La riga ventisei fa in modo che a tutte le richieste al server Express venga applicato il middleware di verifica token scritto precedentemente.

Successivamente, nelle righe dalla ventotto alla trentuno, viene definito un endpoint, quello specifico dell’occupazione del suolo. In questo caso, non è esplicitato nessun parametro e nemmeno nessun codice che gestisce l’inserimento della richiesta di occupazione del suolo. Con questo esempio mi interessava principalmente far comprendere l’utilizzo dell’autenticazione con il token JWT.

Le righe dalla trentatré alla trentacinque descrivono l’ascolto del server Express nella porta 3000 come indicato precedentemente.

Pagina Successiva | Pagina Precedente