Il middleware non è un posto. È un momento.
Ogni framework ha un file che si chiama middleware, e ogni team ci mette dentro cose diverse. L'autorizzazione è l'unica che non può stare altrove: perché una pagina ha tre porte, perché un ruolo salvato in sessione non si revoca, e qual è il momento in cui la regola deve esistere una volta sola.
Nei progetti che eredito, la domanda "dove sta l'autorizzazione?" ha quasi sempre la stessa risposta: un po' ovunque. Un controllo nel loader della pagina, uno nell'endpoint dell'API, uno nel componente che nasconde il bottone, uno nel middleware che redirige al login. Quattro posti, quattro versioni della stessa regola, e nessuno sa quale vinca quando divergono — finché un utente non scopre che divergono.
Il problema non è che il middleware sia un brutto posto per l'autorizzazione. È che lo trattiamo come un posto, quando è un momento: quello in cui una richiesta è già identificata ma non ha ancora fatto niente. Tutto ciò che decide chi può deve succedere lì, una volta, prima di qualunque lavoro. Il resto è conseguenza.
Una pagina ha tre porte
Un'applicazione con rendering sul server non serve una pagina in un modo solo. La stessa pagina arriva come documento HTML al primo caricamento, come JSON delle props quando la navigazione avviene lato client, e come risposta a un'azione quando un form viene inviato. Tre richieste diverse, tre URL diversi o quasi, tre punti d'ingresso.
Una guardia scritta nel loader protegge la prima porta. Spesso anche la seconda, se il framework è onesto. Quasi mai la terza: l'azione del form gira per conto suo, e se la regola vive nel loader, l'azione non la vede. Ho trovato questo buco in applicazioni fatte bene, da persone attente: non è distrazione, è che la regola era nel posto sbagliato e il framework non diceva quante porte stesse aprendo.
Il momento giusto è prima delle tre porte, non dentro una di esse. Un middleware che decide una volta per quel percorso — e che il framework applica a documento, props e azione senza chiedere al programmatore di ricordarselo — chiude il buco per costruzione.
Il ruolo in sessione non si revoca
Secondo classico: il ruolo salvato nel cookie di sessione. L'utente fa login, la sessione dice role: admin, e ogni controllo da lì in poi legge quel campo. Veloce, comodo, e sbagliato nell'unico caso che conta: quando quell'utente smette di essere admin. Il cookie firmato continua a dire admin fino a quando scade, e nessun logout altrui lo cambia.
L'alternativa non è smettere di usare la sessione. È distinguere chi sei — che la sessione può provare, perché la firma lo garantisce — da cosa puoi — che deve essere letto da una fonte revocabile al momento della decisione. Uno store, una tabella, una cache con un orologio: qualcosa che un'azione amministrativa può cambiare adesso, senza aspettare che un cookie muoia.
E quando il framework offre un gancio per questo — una funzione che gira su ogni sessione verificata e può dire "non più valida" — la revoca diventa un'operazione, non un'architettura. Scrivi una riga che legge l'ora dell'ultimo "esci ovunque" e la confronta con quando la sessione è stata emessa: ogni dispositivo perde l'accesso alla richiesta successiva, senza toccare nessun cookie.
La regola esiste una volta, o esiste quattro volte male
Il principio che ne esce è noioso e quindi utile: la decisione vive nel momento in cui la richiesta è identificata, ed esiste una volta sola. Il loader, l'endpoint, l'azione e il componente la leggono; non la rifanno. Se il middleware ha deciso che questo utente può vedere il workspace 12, il loader riceve quel fatto — un valore inoltrato, non un ruolo da ricalcolare — e il bottone nascosto resta ciò che è: cosmesi, non sicurezza.
Il test per sapere se ci sei è semplice. Prendi una regola — "solo i membri vedono il canale" — e cerca nel codice quante volte è scritta. Se la risposta è maggiore di uno, prima o poi divergeranno. Se la risposta è uno ma non è nel momento prima delle tre porte, una delle porte è aperta. Se è uno ed è lì, puoi smettere di preoccuparti di quella regola e iniziare a preoccuparti della prossima.
Cosa fare lunedì
Apri il file che il tuo framework chiama middleware e leggi cosa c'è dentro. Logging, header, redirect di localizzazione: va bene, ma non è il motivo per cui esiste. Poi apri una pagina protetta e conta le porte da cui si entra. Poi apri la sessione e cerca la parola role. Tre file, un'ora, e sai esattamente quante volte la tua autorizzazione è scritta e in quanti momenti diversi viene presa. Quasi sempre è più di quello che si pensava, e quasi sempre si sistema in una giornata.