๐๐๐๐ฒ๐ป๐๐ถ๐ฐ๐ฎ๐๐ถ๐ผ๐ป๐ฒ, ๐ฟ๐๐ผ๐น๐ถ ๐ฒ ๐ฎ๐ฐ๐ฐ๐ฒ๐๐๐ผ ๐ฎ๐น๐นโ๐ฎ๐ฟ๐ฒ๐ฎ ๐ฎ๐ฑ๐บ๐ถ๐ป
Sito web personale โ Da 0 a Deploy ยท Episodio 4 ยท 04 giugno 2026
In questo episodio racconto come il sito ha iniziato a distinguere chi puรฒ solo leggere da chi puรฒ gestire i contenuti. Attraverso il linguaggio naturale ho descritto ruoli, permessi, login, password protette e accesso admin. LโAI ha tradotto questa logica in un sistema di autenticazione con JWT, bcrypt, cookie sicuri e middleware di controllo.
Ogni sistema digitale che gestisce contenuti deve rispondere a tre domande fondamentali:
๐๐ต๐ถ ๐๐ฒ๐ถ?
๐๐ผ๐๐ฎ ๐ฝ๐๐ผ๐ถ ๐ณ๐ฎ๐ฟ๐ฒ?
๐๐ผ๐บ๐ฒ ๐น๐ผ ๐ฑ๐ถ๐บ๐ผ๐๐๐ฟ๐ถ๐ฎ๐บ๐ผ?
Nel quarto episodio della serie โDa 0 a Deployโ racconto come รจ nato il sistema di ๐ฎ๐๐๐ฒ๐ป๐๐ถ๐ฐ๐ฎ๐๐ถ๐ผ๐ป๐ฒ del mio sito web: la parte che permette di distinguere un semplice visitatore da un amministratore.
Fino a quel momento il sito aveva giร una struttura, un database e diverse sezioni pronte per essere alimentate: articoli, eventi, esperienze, formazione, newsletter, messaggi e profilo.
Mancava perรฒ un passaggio fondamentale: stabilire ๐ฐ๐ต๐ถ ๐ฝ๐ผ๐๐ฒ๐๐๐ฒ ๐บ๐ผ๐ฑ๐ถ๐ณ๐ถ๐ฐ๐ฎ๐ฟ๐ฒ ๐ฐ๐ผ๐๐ฎ.
Perchรฉ un sito dinamico non รจ solo un insieme di pagine. ร un sistema in cui alcune persone leggono, altre interagiscono e qualcuno deve poter gestire i contenuti in modo sicuro.
La logica iniziale era semplice: io sono lโ๐ฎ๐ฑ๐บ๐ถ๐ป e posso creare, modificare e cancellare i contenuti. Gli altri utenti possono leggere, iscriversi alla newsletter, inviare messaggi dal form contatti e interagire con le sezioni pubbliche.
Questa distinzione รจ il cuore di due concetti fondamentali:
๐๐๐๐ฒ๐ป๐๐ถ๐ฐ๐ฎ๐๐ถ๐ผ๐ป๐ฒ: chi sei?
๐๐๐๐ผ๐ฟ๐ถ๐๐๐ฎ๐๐ถ๐ผ๐ป๐ฒ: cosa sei autorizzato a fare?
Ho descritto questa logica allโAI in linguaggio naturale, chiedendo di implementare un sistema completo con registrazione, login, password protette, token di sessione, logout e controllo degli accessi alle aree riservate.
La richiesta era chiara: le pagine pubbliche dovevano restare accessibili a tutti, mentre lโarea admin e le operazioni di modifica dovevano essere protette.
Da questa descrizione sono stati generati diversi componenti tecnici: ๐๐ช๐ง per gestire i token di autenticazione, ๐ฏ๐ฐ๐ฟ๐๐ฝ๐ per proteggere le password, ๐ฐ๐ผ๐ผ๐ธ๐ถ๐ฒ ๐ต๐๐๐ฝ๐ข๐ป๐น๐ per rendere piรน sicura la sessione e un ๐บ๐ถ๐ฑ๐ฑ๐น๐ฒ๐๐ฎ๐ฟ๐ฒ per controllare se lโutente fosse autorizzato ad accedere alle rotte riservate.
Il punto interessante รจ che non sono partito dal codice.
Sono partito dalla logica organizzativa: chi entra, cosa vede, cosa puรฒ modificare e cosa invece deve rimanere protetto.
Uno dei momenti piรน concreti del progetto รจ stato il primo accesso come admin. Fino a quel momento il sito era qualcosa che stava prendendo forma: pagine, database, contenuti demo e struttura generale.
Ma quando ho effettuato il login e ho visto comparire il pannello di controllo, il progetto ha cambiato natura.
Non era piรน solo un sito visibile online.
Era un sistema ๐ฎ๐บ๐บ๐ถ๐ป๐ถ๐๐๐ฟ๐ฎ๐ฏ๐ถ๐น๐ฒ.
Da quel momento potevo gestire articoli, eventi, contenuti, newsletter, messaggi e informazioni personali direttamente dal browser.
Naturalmente, anche qui non รจ stato tutto lineare. Dopo il primo login, alcune pagine admin si caricavano correttamente, ma alcune operazioni restituivano un errore di autorizzazione.
Il problema era nel modo in cui il sistema cercava il token di autenticazione: il login lo salvava in un cookie, mentre il middleware lo cercava nellโheader Authorization.
In pratica, il sito sapeva che avevo fatto login, ma alcune funzioni protette non riuscivano a riconoscermi correttamente come admin.
La soluzione รจ arrivata descrivendo il problema allโAI: il middleware doveva leggere il JWT dal cookie chiamato token, non dallโheader Authorization. Dopo la correzione, il sistema ha iniziato a riconoscere correttamente lโutente autenticato e il ruolo admin.
La lezione principale di questo episodio รจ che la ๐๐ถ๐ฐ๐๐ฟ๐ฒ๐๐๐ฎ non nasce solo dal codice. Nasce prima di tutto da una buona definizione delle regole.
Prima ancora di parlare di token, cookie o middleware, bisogna chiarire chi puรฒ entrare, quali azioni puรฒ compiere, quali sezioni devono essere pubbliche, quali devono essere riservate e cosa accade quando qualcuno prova ad accedere senza permesso.
Queste sono decisioni di ๐ด๐ผ๐๐ฒ๐ฟ๐ป๐ฎ๐ป๐ฐ๐ฒ del sistema.
LโAI puรฒ generare la soluzione tecnica, ma la responsabilitร delle regole resta umana. Sono io che devo decidere chi puรฒ fare cosa. Sono io che devo verificare se il comportamento del sistema รจ coerente con lโobiettivo.
Questo episodio รจ centrale perchรฉ mostra il momento in cui il sito diventa davvero governabile.
Un sito con database conserva informazioni.
Un sito con autenticazione decide chi puรฒ gestirle.
Ed รจ qui che un progetto smette di essere una semplice vetrina e inizia ad assomigliare a un vero prodotto digitale.