Middleware Next.js per Autenticazione e A/B Testing — Come Implementarli senza Complicazioni

Gestire reindirizzamenti per utenti non autenticati o lanciare varianti di test A/B su un'app Next.js tira in ballo decisioni che possono appesantire il frontend o esporre dati sensibili. Il middleware esegue la logica prima che la richiesta arrivi alla pagina — sul server, all'edge. Noi, di Meteora Web, lo usiamo in produzione per evitare controlli lato client che rallentano l'esperienza e per garantire che ogni visitatore veda la variante giusta senza inutili round trip. In questa guida vediamo come applicarlo ai due casi più comuni: autenticazione con redirect e A/B testing lato server.

Cos'è il Middleware Next.js e Perché Usarlo per Autenticazione e A/B Testing?

Il middleware in Next.js è una funzione che viene eseguita per ogni richiesta in ingresso, prima che la route venga renderizzata. Si scrive in middleware.ts nella root del progetto e può modificare la risposta (redirect, rewrite, aggiungere header). È eseguito all'edge o su Node, a seconda della configurazione.

Per l'autenticazione significa che possiamo intercettare richieste a pagine protette e reindirizzare al login senza che il browser riceva mai il contenuto della pagina. Per l'A/B testing, possiamo leggere un cookie o un parametro e instradare l'utente a una versione diversa della pagina, sempre lato server. Questo mantiene il bundle snello e la logica di business centralizzata.

Scenario concreto: un nostro cliente e-commerce voleva mostrare un nuovo layout della scheda prodotto al 50% dei visitatori. Con il middleware abbiamo fatto in modo che il cookie variant determinasse la riscrittura verso /products/[id]?v=b (versione B) senza toccare il codice dei componenti. Il risultato è stato un test A/B pulito, tracciabile via GA4, e senza impatto sul peso delle pagine.

Per chi è indicato

Se hai un'app Next.js con pagine che richiedono login, o se vuoi sperimentare varianti di design senza rifare ogni componente, il middleware è lo strumento giusto. Non serve solo per reindirizzare: puoi anche iniettare dati nelle request (es. l'ID utente) e usarli nei Server Components.

Come Configurare il Middleware Next.js per Reindirizzare Utenti Non Autenticati?

Il caso d'uso più frequente: una dashboard a cui solo gli utenti loggati possono accedere. Se l'utente non ha un token valido (es. JWT in cookie), lo reindirizziamo a /login.

Passo 1: Creare il file middleware.ts

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const token = request.cookies.get('session_token')?.value;

  // Definisci le rotte protette
  const protectedPaths = ['/dashboard', '/account', '/admin'];
  const isProtected = protectedPaths.some((path) =>
    request.nextUrl.pathname.startsWith(path)
  );

  // Se rotta protetta e nessun token, redirect al login
  if (isProtected && !token) {
    const loginUrl = new URL('/login', request.url);
    loginUrl.searchParams.set('redirect', request.nextUrl.pathname);
    return NextResponse.redirect(loginUrl);
  }

  return NextResponse.next();
}

// Configura il matcher per escludere risorse statiche
export const config = {
  matcher: ['/((?!_next/static|favicon.ico|api).*)'],
};

Cosa fa: controlla il cookie session_token. Se manca e la rotta è protetta, redirige a /login salvando il path di destinazione in ?redirect=... per riportare l'utente dopo il login. Il matcher esclude asset statici per non eseguire il middleware su file non necessari.

Passo 2: Verificare il token lato server (opzionale)

In produzione, un semplice controllo di esistenza non basta. Dovresti validare il JWT o chiamare un'API di autenticazione. Il middleware è eseguito su ogni richiesta, quindi le chiamate esterne devono essere rapide. Noi preferiamo usare Edge Middleware con @clerk/nextjs o next-auth/middleware che già gestiscono la validazione dei token con cache locale.

Esempio con next-auth:

export { default } from 'next-auth/middleware';
export const config = { matcher: ['/dashboard', '/account'] };

Più semplice, ma personalizzabile solo attraverso callback. Se hai bisogno di logica custom (es. solo utenti con ruolo admin), il nostro approccio con getToken è più flessibile.

Errore comune da evitare

Non esporre la logica di autenticazione nei componenti client. Abbiamo visto progetti in cui il controllo del token avveniva in un useEffect dopo che la pagina era già stata renderizzata — flash di contenuti privati visibile per un istante. Il middleware previene proprio questo: la richiesta viene bloccata prima che il browser riceva HTML.

Come Implementare un A/B Testing Lato Server con Middleware Next.js?

L'A/B testing tradizionale si fa con JavaScript lato client o con tag manager. Entrambi hanno limiti: l'utente vede per un attimo la versione originale prima che lo script cambi la variante (Flash of Original Content — FOOC). Con il middleware, la variante viene decisa e applicata prima che la risposta venga inviata.

Strategia: cookie o parametro URL

Il middleware può leggere un cookie (es. ab_test_variant) o un parametro URL, e riscrivere il path verso una sottocartella o aggiungere un header. Noi consigliamo di usare una rewrite interna per mantenere l'URL pulito.

Codice per un A/B test su homepage

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const url = request.nextUrl.clone();

  // Solo per la homepage
  if (url.pathname === '/') {
    // Leggi il cookie existente o assegna casualmente
    let variant = request.cookies.get('ab_variant')?.value;
    if (!variant) {
      variant = Math.random() < 0.5 ? 'a' : 'b';
      const response = NextResponse.next();
      response.cookies.set('ab_variant', variant, {
        maxAge: 60 * 60 * 24 * 30, // 30 giorni
        path: '/',
        sameSite: 'lax',
        secure: process.env.NODE_ENV === 'production',
      });
      return response;
    }

    // Se è variante B, riscrivi la homepage a /b
    if (variant === 'b') {
      url.pathname = '/b';
      return NextResponse.rewrite(url);
    }
  }

  return NextResponse.next();
}

export const config = {
  matcher: ['/'],
};

In questo esempio, la homepage di default è la variante A (/). La variante B è servita da /b (che può essere una pagina diversa o un gruppo di componenti differenti). La riscrittura (rewrite) fa sì che l'URL rimanga / per l'utente, ma internamente Next.js renderizza la pagina /b. Nessun redirect visibile.

Tracciamento con Google Analytics 4

Per misurare i risultati, invia un evento experiment_view lato client con la variante leggendo il cookie:

// components/AbTracker.js
'use client';
import { useEffect } from 'react';

export default function AbTracker() {
  useEffect(() => {
    const variant = document.cookie.match(/(?:^|; )ab_variant=([^;]*)/);
    if (variant) {
      gtag('event', 'experiment_view', {
        experiment_id: 'homepage_layout_v1',
        variant: variant[1],
      });
    }
  }, []);
  return null;
}

Inserisci <AbTracker /> nel layout della homepage.

Alternativa: header di risposta

Se preferisci gestire la logica lato server senza cookie, puoi aggiungere un header X-Variant e usare un Server Component per decidere quale layout mostrare in base all'header. Il middleware inietta l'header:

const response = NextResponse.next();
response.headers.set('x-variant', variant);
return response;

Poi nel Server Component leggi header('x-variant') con headers() dalla next/headers.

Quali Sono le Best Practice per Non Rovinare l'Esperienza Utente?

Il middleware è potente, ma va usato con cautela. Ecco le regole che seguiamo nei progetti reali.

1. Matcher preciso, non eseguire su tutto

Il matcher riduce le invocazioni. Noi settiamo regex per includere solo le rotte che ci servono. Esempio: ['/dashboard/:path*', '/account/:path*', '/'] invece di un catch-all. Su siti con centinaia di pagine, questo evita overhead inutile.

2. Non usare il middleware per chiamate API lente

Se devi validare un token contro un database esterno, fallo in una API Route, non nel middleware. Il middleware Next.js non supporta operazioni asincrone bloccanti che richiedono più di pochi millisecondi. In caso di necessità, usa Edge Middleware con piccole librerie come jose per decodificare JWT localmente.

3. Mantieni lo stato utente in cookie o JWT, non in variabili globali

Il middleware non ha accesso a sessioni server-side (non c'è una sessione persistente). Usa cookie firmati o token. Per l'A/B testing, un cookie con scadenza lunga è sufficiente. Per l'autenticazione, usa next-auth che gestisce automaticamente i cookie di sessione.

4. Testa i redirect con gli spider dei motori di ricerca

Se reindirizzi pagine pubbliche (es. homepage di test), assicurati che i crawler vedano sempre la versione corretta e non vengano reindirizzati a loop. Per l'A/B testing, conviene rendere la variante di controllo sempre accessibile e usare il cookie solo per gli umani.

Cosa Fare Adesso

Per mettere subito in pratica quanto visto:

1. Aggiungi un middleware di autenticazione al tuo progetto Next.js. Crea middleware.ts nella root, definisci le rotte protette e testa il redirect verso /login.
2. Implementa un semplice A/B test sulla homepage con cookie e rewrite. Crea due varianti di layout (es. app/page.tsx e app/b/page.tsx) e verifica che il cookie ab_variant venga impostato.
3. Controlla i log delle richieste per assicurarti che il middleware non introduca latenza. Next.js mostra il tempo di esecuzione nel server log. Dovrebbe essere sotto 1 ms.
4. Leggi la documentazione ufficiale per approfondire: Next.js Middleware Docs.
5. Esplora il nostro articolo sul pillar per una visione più ampia su Next.js App Router: Next.js App Router, Server Components e Data Fetching.

Il middleware non è solo una scorciatoia: è il modo giusto per tenere l'autenticazione e i test lato server senza appesantire il frontend. Noi lo usiamo ogni giorno e ne vediamo i benefici in termini di performance e manutenibilità.