Quick note: Middleware come Chain of Responsibility

Ogni anello decide se passare al successivo

Lo stack middleware di Soft PHP MVC e una Chain of Responsibility: ogni middleware riceve la request, decide se gestirla o passarla al successivo, e può modificare la response in uscita. CsrfMiddleware verifica il token — se manca, risponde 403 e la catena si interrompe. RateLimitMiddleware conta le richieste — se il limite e superato, risponde 429. AuthMiddleware verifica la sessione — se non autenticato, redirige al login. Ogni anello e un filtro autonomo con una logica precisa.

La potenza del pattern e nella composibilita: l'ordine dei middleware conta, ma ogni middleware e indipendente. Puoi aggiungere, rimuovere o riordinare anelli senza toccare gli altri. Il VisitorTrackingMiddleware e stato aggiunto alla catena senza modificare una riga dei middleware esistenti — e questo e il test definitivo di un buon Chain of Responsibility. L'Open/Closed Principle in azione: la catena e aperta all'estensione (nuovi anelli), chiusa alla modifica (anelli esistenti non cambiano).

Cos'e il Chain of Responsibility: definizione formale

Il Gang of Four definisce il Chain of Responsibility come un pattern comportamentale che "evita di accoppiare il mittente di una richiesta al suo destinatario, dando a più oggetti la possibilita di gestire la richiesta. Gli oggetti riceventi vengono concatenati e la richiesta viene passata lungo la catena fino a quando un oggetto la gestisce". I due elementi chiave sono: l'Handler (l'interfaccia comune a tutti gli anelli) e la catena (la sequenza ordinata di handler).

A differenza dell'Observer, dove tutti gli osservatori vengono notificati, nella Chain of Responsibility la richiesta può fermarsi a qualsiasi anello. Un middleware che risponde con un errore 403 interrompe la catena — i middleware successivi non vengono eseguiti. Questa capacità di cortocircuito e fondamentale per la sicurezza: il CsrfMiddleware deve poter bloccare una richiesta malevola prima che raggiunga il controller.

L'anatomia di un middleware in Soft PHP MVC

Ogni middleware nel framework implementa un contratto semplice: riceve la request e un callable che rappresenta il prossimo anello della catena. Il middleware può:

• Passare la request al successivo — chiama il callable e restituisce la response (middleware trasparente)
• Modificare la request — aggiunge header, normalizza input, poi passa al successivo
• Interrompere la catena — restituisce una response direttamente (errore, redirect, cache hit)
• Modificare la response — chiama il successivo, poi modifica la response prima di restituirla

Questa flessibilita rende il middleware una primitiva estremamente potente. Non e un caso che la quasi totalita dei framework PHP moderni — Laravel, Symfony, Slim — adotti lo stesso pattern per il request handling. La Chain of Responsibility nel contesto HTTP e diventata uno standard de facto dell'ecosistema PHP.

Middleware concreti nel framework

Lo stack middleware di Soft PHP MVC include anelli con responsabilità diverse:

• CsrfMiddleware — verifica il token CSRF su richieste POST/PUT/DELETE, protegge da attacchi cross-site request forgery
• RateLimitMiddleware — limita le richieste per IP in una finestra temporale, previene abusi e DDoS
• AuthMiddleware — verifica l'autenticazione, redirige al login se la sessione e scaduta
• VisitorTrackingMiddleware — traccia i visitatori unici per analytics, senza bloccare la request
• MaintenanceModeMiddleware — intercetta tutte le richieste e mostra la pagina di manutenzione quando attivo

L'ordine e significativo: il CSRF check avviene prima dell'auth, perché una richiesta senza token valido non dovrebbe nemmeno arrivare al controllo dell'autenticazione. Il rate limiting avviene prima di tutto, perché un attacco brute force non dovrebbe consumare risorse per verificare token o sessioni.

Pipeline pattern: l'evoluzione del Chain of Responsibility

In molti framework moderni, il Chain of Responsibility per i middleware e implementato come Pipeline: un oggetto che riceve una lista di handler e li esegue in sequenza, passando il risultato di uno come input del successivo. La Pipeline e una variante più strutturata della catena classica — invece di lasciare che ogni anello conosca il successivo, la pipeline li orchestra dall'esterno.

In Soft PHP MVC, il kernel HTTP costruisce la pipeline al boot dell'applicazione, concatenando i middleware configurati nel file di routing. La pipeline e immutabile dopo la costruzione: l'ordine degli anelli non cambia durante l'esecuzione. Questa immutabilita semplifica il debugging e garantisce un comportamento predicibile — la stessa request attraversa sempre gli stessi anelli nello stesso ordine.

Quando usare la Chain of Responsibility

Il pattern e ideale quando:

• Più oggetti possono gestire una richiesta e il gestore corretto non e noto a priori
• L'ordine di gestione e importante ma deve essere configurabile
• Nuovi gestori devono poter essere aggiunti senza modificare quelli esistenti
• Una richiesta deve poter essere rifiutata a qualsiasi livello della catena

Oltre ai middleware HTTP, la Chain of Responsibility si applica a validazione (ogni regola e un anello che può bloccare), logging (ogni handler decide se loggare e a quale livello), e event handling (ogni listener può marcare l'evento come gestito). In Soft PHP MVC, il middleware e l'applicazione principale, ma il pattern e una risorsa architetturale disponibile ogni volta che serve una catena decisionale configurabile e aperta all'estensione.

👉 Leggi l'articolo completo su iadicola.it