Un flujo de auth completo: login, sesión, middleware y logout

Tienes todas las piezas sueltas: sesiones selladas, middleware con event.locals, cookies endurecidas y guardias junto al dato. Esta lección las ensambla en un flujo de autenticación completo y las hace hablar entre sí. Verás cómo un login se modela como una action que verifica credenciales y acuña autoridad sembrando la sesión; cómo un middleware puebla event.locals.user en cada petición de servidor para que el resto del código no relea la sesión; cómo el guardia decide junto al dato sin depender jamás de que el middleware haya corrido; y cómo un logout revoca esa autoridad limpiando la sesión. Cinco verbos —acuñar, portar, poblar, decidir, revocar— y un solo bucle que se cierra sobre sí mismo. Este es el patrón que sostiene la mayoría de las apps con usuarios de SolidStart.

El mapa del flujo

Antes del código, la coreografía. El usuario envía sus credenciales; la acción de servidor las verifica y, si son válidas, escribe su identidad en la sesión sellada y lo redirige a la zona privada. En cada petición posterior, el middleware lee esa sesión y deja el usuario resuelto en event.locals, y el guardia de la ruta vuelve a confirmar junto al dato. El logout limpia la sesión y devuelve al login.

sequenceDiagram
participant U as Usuario
participant F as Formulario login
participant A as loginAction en servidor
participant S as Sesion sellada
participant M as Middleware
participant P as Ruta panel
U->>F: envia email y password
F->>A: dispara la action
A->>S: session update con userId
A-->>U: throw redirect a panel
U->>M: peticion a panel
M->>S: lee la sesion
M->>M: puebla event locals user
P->>P: requireUser confirma junto al dato
P-->>U: panel renderizado

Login: una action que verifica y siembra la sesión

El login es una mutación: cambia el estado del servidor, así que se modela con action. Verifica las credenciales; si fallan, devuelve un Error para que el formulario lo pinte; si aciertan, siembra la sesión y lanza una redirección. Esa asimetría es deliberada: devolver comunica un resultado que la interfaz muestra; lanzar un redirect cambia de página.

// src/lib/auth.ts
import { action, redirect } from "@solidjs/router";
import { usarSesion } from "./sesion";
import { verificarCredenciales } from "./db";

export const loginAction = action(async (formData: FormData) => {
  "use server";
  const email = String(formData.get("email"));
  const password = String(formData.get("password"));

  const user = await verificarCredenciales(email, password);
  if (!user) return new Error("Credenciales invalidas"); // el form lo muestra

  const sesion = await usarSesion();
  await sesion.update({ userId: user.id });   // acuna autoridad: siembra la sesion
  throw redirect("/panel");                   // exito: cambia de pagina
}, "login");

export const logoutAction = action(async () => {
  "use server";
  const sesion = await usarSesion();
  await sesion.clear();       // revoca la autoridad de este cliente
  throw redirect("/login");
}, "logout");

El formulario ata la acción con action={loginAction} y method="post", lo que le da mejora progresiva: funciona incluso sin JavaScript, porque es un envío de formulario real. useSubmission expone el envío en vuelo —su pending para deshabilitar el botón, su result para leer el Error devuelto—.

// src/routes/login.tsx
import { useSubmission } from "@solidjs/router";
import { Show } from "solid-js";
import { loginAction } from "~/lib/auth";

export default function Login() {
  const enviando = useSubmission(loginAction);
  return (
    <form action={loginAction} method="post">
      <input name="email" type="email" required />
      <input name="password" type="password" required />
      <button disabled={enviando.pending}>Entrar</button>
      <Show when={enviando.result instanceof Error}>
        <p role="alert">{(enviando.result as Error).message}</p>
      </Show>
    </form>
  );
}

El middleware que puebla el usuario

Con la sesión sembrada, cada petición de servidor puede resolver al usuario una sola vez y dejarlo listo para todos. Ese es el trabajo del middleware: leer la sesión y depositar el resultado en event.locals.user. Es un acelerador, no un guardia; su función es ahorrar relecturas, no autorizar.

// src/middleware/index.ts
import { createMiddleware } from "@solidjs/start/middleware";
import { usarSesion } from "~/lib/sesion";
import { buscarUsuario } from "~/lib/db";

export default createMiddleware({
  onRequest: async (event) => {
    const sesion = await usarSesion();
    const userId = sesion.data.userId;
    event.locals.user = userId ? await buscarUsuario(userId) : null;
  },
});

Recuerda el getUser de la lección anterior: usaba event.locals.user como atajo pero volvía a leer la sesión si el atajo faltaba. Ahí está la robustez del diseño: si el middleware corrió, el guardia va rápido; si no corrió —una navegación de cliente—, el guardia lee la sesión él mismo. La corrección nunca cuelga del middleware; el middleware solo la abarata.

Logout y la ruta protegida: el círculo se cierra

El logout es la acción inversa del login: session.clear revoca la autoridad y redirect devuelve al login. Y la ruta protegida reutiliza requireUser en su preload, de modo que solo un usuario con sesión válida la ve. El bucle está cerrado: se entra sembrando la sesión, se permanece porque el guardia la valida, se sale limpiándola.

// src/routes/panel.tsx
import { createAsync, type RouteDefinition } from "@solidjs/router";
import { logoutAction } from "~/lib/auth";
import { requireUser } from "~/lib/guardias";

export const route = {
  preload: () => requireUser(),   // guardia: sin sesion, redirige a login
} satisfies RouteDefinition;

export default function Panel() {
  const user = createAsync(() => requireUser());
  return (
    <>
      <h1>Hola, {user()?.email}</h1>
      <form action={logoutAction} method="post">
        <button>Salir</button>
      </form>
    </>
  );
}