Quella volta che un middleware mi ha salvato da un disastro

Era un sabato sera di novembre, stavo cenando con amici quando mi arriva una chiamata. Il display mostrava il numero di un cliente con un e-commerce di prodotti enogastronomici. Suonata di sabato sera = problema grosso.

"Alex, il sito è impazzito. Gli ordini si duplicano, alcuni clienti hanno pagato due volte. Che casino è successo?"

Ho lasciato il tavolo, aperto il laptop e mi sono collegato al server. Quello che ho visto mi ha fatto gelare il sangue: in 20 minuti erano arrivati 47 ordini duplicati. Alcuni triplicati. PayPal aveva processato tutto.

Il problema: doppi clic e connessioni lente

Il bug era subdolo. Durante il Black Friday avevamo avuto un picco di traffico inaspettato (bene!) ma alcuni utenti con connessioni lente cliccavano due o tre volte sul pulsante "Conferma ordine" perché la pagina non rispondeva subito. Laravel processava ogni richiesta come ordine nuovo.

Classico. Banale. Devastante.

Ma ecco il colpo di scena: tre mesi prima, mentre lavoravo a un gestionale personalizzato per un altro cliente, avevo implementato un middleware per prevenire esattamente questo tipo di problema. L'avevo chiamato PreventDuplicateRequests.

L'avevo scritto quasi per sfizio, dopo aver letto un thread su Reddit dove uno sviluppatore raccontava un disastro simile. "Meglio averlo e non servirmi" pensai. E invece...

Come funziona un middleware anti-duplicati

Il concetto è semplice ma efficace. Il middleware intercetta le richieste POST critiche (checkout, pagamenti, form importanti) e genera un token univoco basato su utente + azione + timestamp. Se riceve la stessa richiesta entro una finestra temporale (io uso 10 secondi), la blocca.

namespace App\Http\Middleware;

use Closure;
use Illuminate\Support\Facades\Cache;

class PreventDuplicateRequests
{
    public function handle($request, Closure $next)
    {
        if ($request->isMethod('post')) {
            $key = $this->generateRequestKey($request);
            
            if (Cache::has($key)) {
                return response()->json([
                    'error' => 'Richiesta duplicata rilevata'
                ], 429);
            }
            
            Cache::put($key, true, 10);
        }
        
        return $next($request);
    }
    
    private function generateRequestKey($request)
    {
        return 'request_' . md5(
            $request->user()->id .
            $request->path() .
            $request->ip()
        );
    }
}

Nel caso dell'e-commerce quella sera, avevo già il middleware pronto. Mi è bastato applicarlo alle rotte del checkout in 5 minuti, deploy, e il problema si è fermato immediatamente.

Lezioni apprese (sulla mia pelle)

Primo: non tutti i bug si manifestano in sviluppo. Questo funzionava perfettamente nei test, ma con connessioni lente reali e utenti nervosi che cliccavano furiosamente... boom.

Secondo: i middleware sono incredibilmente potenti. Li uso per tantissime cose oltre alla sicurezza: logging automatico, rate limiting, gestione delle sessioni. Quando lavoro su web app su misura, sono sempre il primo layer di difesa che implemento.

Terzo: quella sera ho capito il valore della documentazione ufficiale di Laravel sui middleware. Non è solo teoria, è roba che ti salva il sabato sera.

Quarto: prevenire è meglio che curare. Quel middleware "per sfizio" mi ha evitato ore di rimborsi manuali, email di scuse, e probabilmente la perdita del cliente.

Altre situazioni dove i middleware mi hanno salvato

Da quella sera ho iniziato a usare middleware personalizzati per mille cose. Ne ho uno che blocca accessi da IP sospetti dopo 3 tentativi falliti. Un altro che forza HTTPS su tutte le rotte sensibili. Uno che logga automaticamente tutte le azioni admin in un gestionale.

Per un cliente con un sistema di prenotazioni online ho creato un middleware che verifica la disponibilità in tempo reale prima di ogni tentativo di prenotazione, evitando overbooking. Sembra banale ma vi assicuro che senza quello controllo centralizzato sarebbe stato un inferno di if-else sparsi nel codice.

Il bello dei middleware Laravel è che sono modulari. Li scrivi una volta, li testi bene, e poi li riusi in progetti diversi. Ho una cartella nel mio sistema con una decina di middleware pronti all'uso che importo praticamente sempre.

Come gestisco oggi la sicurezza delle richieste

Dopo quella vicenda, ogni progetto che coinvolge transazioni o azioni critiche include di default:

• Middleware anti-duplicati sulle rotte POST critiche
• Token CSRF nativi di Laravel (che già ci sono ma li verifico sempre)
• Rate limiting aggressivo sulle API esposte
• Logging dettagliato di ogni azione che tocca il database
• Disabilitazione lato frontend del pulsante submit dopo il primo clic (ma non basta mai!)

Quest'ultimo punto è importante: la validazione lato client è comoda per l'utente, ma quella lato server è essenziale. Mai fidarsi del frontend. Mai.

Il cliente dell'e-commerce? Dopo quella sera mi ha ringraziato per la gestione rapida (e per il middleware che aveva limitato i danni). Lavoriamo ancora insieme. E sì, ho aggiunto quella vicenda nel mio portfolio progetti come caso studio - versione edulcorata, ovviamente.

Se stai sviluppando con Laravel, o stai pensando di far realizzare un gestionale o una web app, i middleware devono essere parte della conversazione. Non sono un optional, sono uno strumento fondamentale. E possono davvero salvarti da disastri in produzione, credimi sulla parola.

Hai mai avuto un sabato sera rovinato da un bug in produzione? O hai implementato soluzioni simili per prevenire problemi? Se vuoi confrontarti o hai bisogno di una mano con Laravel, scrivimi pure. Magari davanti a un caffè, meglio se non di sabato sera.