Cómo añadir la autenticación de usuarios de Firebase a un sitio de membresía en Webflow

Firebase Authentication te permite obtener un usuario con sesión iniciada en el navegador tras configurar un proveedor. Webflow eliminó su función nativa de Cuentas de Usuario el 29 de enero de 2026, por lo que la plataforma ya no cuenta con autenticación propia y la identidad debe provenir de otro lugar.

Un área de miembros requiere que el servidor rechace la renderización de una página ante cualquier solicitud que carezca de un token verificado. Ese rechazo debe ocurrir en un lugar al que el SDK de cliente de Firebase no pueda acceder.

En un sitio de Webflow, ese servidor es una aplicación de Next.js montada a través de Webflow Cloud. Se ejecuta en Cloudflare Workers. Esta configuración almacena un token de ID verificado por el servidor en una httpOnly cookie desde un Route Handler y permite middleware.ts redirigir a cualquier persona sin una cookie válida a la página de inicio de sesión.

¿Qué necesitas para añadir la autenticación de Firebase en Webflow?

Necesitas cuatro requisitos previos. Webflow Cloud está disponible desde el plan de sitio Starter gratuito en adelante, mientras que montar la aplicación de miembros en un dominio personalizado requiere el plan Premium o superior.

Antes de empezar, prepara tu sitio de Webflow, tu proyecto de Firebase, tus herramientas de desarrollo local y tus conocimientos sobre el framework.

Reúne estos requisitos previos:

• Sitio de Webflow: Crea el sitio que alojará la aplicación montada bajo su ruta configurada en Webflow Cloud.
• Proyecto de Firebase: Usa una cuenta de Google y habilita Firebase Authentication con el proveedor de Correo/Contraseña para esta configuración.
• Node.js 22 o posterior, con npm: La página de "bring-your-own-app" establece ese requisito mínimo, y como Webflow Cloud solo admite npm, evita usar pnpm y yarn para este proyecto.
• Conocimientos de TypeScript y App Router: Prepárate para trabajar con Route Handlers de Next.js, componentes de cliente, layouts de App Router y un archivo de middleware.

Con estos elementos listos, puedes configurar primero la identidad y, después, conectar el navegador, la sesión del servidor y las rutas protegidas.

6 pasos para añadir la autenticación de Firebase en Webflow Cloud

Estos seis pasos crean una aplicación de miembros montada que inicia la sesión de los usuarios, verifica los tokens de ID de Firebase con Web Crypto, actualiza su cookie y redirige las solicitudes no autenticadas antes de que se rendericen las páginas protegidas.

El proceso avanza desde la configuración de Firebase y Webflow Cloud hasta el inicio de sesión del cliente, la verificación del servidor, la sincronización de sesiones y la restricción de rutas basada en middleware.

1. Configura Firebase Authentication y autoriza tu dominio de Webflow

Configura la autenticación de Correo/Contraseña y autoriza el dominio que servirá la aplicación montada. En la consola de Firebase, crea un proyecto, ve a Build, abre Authentication y haz clic en Empezar. En la pestaña de método de inicio de sesión, elige Correo/Contraseña, activa el interruptor y guarda los cambios.

Vale la pena configurar los dominios autorizados ahora, aunque esta compilación no los active: la lista controla las operaciones de ventanas emergentes y redirecciones de OAuth, así como las URL de continuación, pero no el endpoint de correo y contraseña que usamos aquí. Esto empieza a ser importante en cuanto añades Google u otro proveedor.

Sin salir de Authentication, abre la pestaña Settings y busca Authorized domains. Añade el dominio desde el que se servirá el área de miembros: el dominio que usas para las pruebas ahora y tu dominio personalizado cuando hagas el cambio.

El dominio de Webflow no aparece en la lista de forma predeterminada, y el inicio de sesión con un proveedor desde un dominio no incluido en la lista fallará.

Luego abre Project settings (el icono de engranaje junto a Project Overview), desplázate hasta Your apps en la pestaña General y añade una Web app. Copia el objeto de configuración después de registrar la aplicación. Su apiKey identifica el proyecto ante el SDK del cliente.

También usarás los valores de authDomain y projectId . En la pestaña Users de Authentication, añade un usuario de prueba con correo y contraseña para tener credenciales con las que probar más adelante.

Ahora deberías ver Email/Password listado como activo en Sign-in method, tu dominio de Webflow en Authorized domains y un usuario en la lista Users.

2. Crea la aplicación Next.js y móntala en Webflow Cloud

Crea un proyecto de Next.js compatible con npm para la ruta de montaje /members . La página de traer tu propia aplicación indica que Webflow Cloud es compatible con Next.js 15 o superior, Astro 6 o 7, y Vite 6.1 o superior.

Crea la estructura con una versión principal explícita, no con la etiqueta flotante @latest :

npx create-next-app@15 firebase-members --typescript --app --eslint --no-src-dir --no-tailwind --import-alias "@/*" --use-npm
cd firebase-members
npm install firebase jose

La @15 realiza una función de seguridad, no solo de compatibilidad. next@latest es la 16, donde middleware.ts está obsoleta en favor de proxy.ts, y la documentación de Next.js indica que "Proxy utiliza por defecto el entorno de ejecución de Node.js" y que "la opción de configuración no está disponible en los archivos Proxy".

Webflow Cloud solo ejecuta middleware en el entorno Edge, por lo que en la versión 16 el filtro del paso 6 deja de funcionar y el área de miembros queda abierta a todo el mundo. Si usas la versión 15, mantente en la 15.2.3 o superior: las versiones 15.x anteriores contienen la vulnerabilidad GHSA-f82v-jwr5-mffw, un fallo crítico de omisión de autorización que permite que una solicitud manipulada se salte el middleware.

Dado que el middleware es el único control en esta compilación, fijar una versión antigua es dejar una puerta abierta. @15 resuelve a la versión 15.x más reciente, lo que soluciona ambos problemas.

--no-src-dirmantiene lib/ y components/ en la raíz del proyecto para que el alias @/* en las importaciones de abajo se resuelva correctamente.

Eso te proporciona un proyecto con App Router y un package-lock.json , lo cual es coherente con la compatibilidad exclusiva para npm.

Configuración del entorno de Webflow Cloud

En Webflow Cloud, configura un entorno para la aplicación con la ruta de montaje /members . No añadas basePath a next.config ; Webflow Cloud inyecta la ruta de montaje durante la compilación, por lo que configurarla tú mismo entraría en conflicto con el valor inyectado.

En el panel de variables de entorno, añade los valores que copiaste de Firebase:

• NEXT_PUBLIC_FIREBASE_API_KEY: Añade la apiKey que identifica el proyecto ante el SDK del cliente de navegador de Firebase y conecta la instancia de autenticación del cliente con su configuración.
• NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN: Añade el authDomain , normalmente your-project.firebaseapp.com, para que el SDK del cliente pueda gestionar las redirecciones y ventanas emergentes de inicio de sesión para el proyecto de Firebase configurado.
• NEXT_PUBLIC_FIREBASE_PROJECT_ID: Añade el projectId , que dirige al cliente y al servidor al mismo proyecto de Firebase y sirve como audiencia de token esperada durante la verificación.
• NEXT_PUBLIC_BASE_PATH: Establece el prefijo de solicitud del lado del cliente de la aplicación montada en /members para que las solicitudes de inicio de sesión y actualización de tokens lleguen al controlador de rutas de sesión.

Webflow Cloud pone las variables de entorno a disposición tanto de la compilación como de la aplicación desplegada en tiempo de ejecución, por lo que NEXT_PUBLIC_ los valores llegan al paquete del cliente y el servidor puede leer el ID del proyecto sin necesidad de una segunda copia.

Una vez finalizado el primer despliegue, al visitar la URL desplegada de la aplicación en /members debería mostrarse la página predeterminada de Next.js.

3. Instala los paquetes de Firebase y jose e inicializa el cliente

Instala versiones verificadas por el registro y fijadas explícitamente del SDK web de Firebase para el navegador y jose para el servidor, luego crea un módulo de cliente de Firebase reutilizable. React Fast Refresh puede inicializar un módulo más de una vez durante el desarrollo, por lo que el módulo necesita reutilizar una aplicación de Firebase existente.

En esta compilación, el paquete firebase se ejecuta solo en el navegador. jose se ejecuta en el servidor.

Crea el módulo del cliente en lib/firebase-client.ts:

import { initializeApp, getApps, getApp } from 'firebase/app';
import { getAuth } from 'firebase/auth';

const firebaseConfig = {
  apiKey: process.env.NEXT_PUBLIC_FIREBASE_API_KEY,
  authDomain: process.env.NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN,
  projectId: process.env.NEXT_PUBLIC_FIREBASE_PROJECT_ID,
};

const app = getApps().length ? getApp() : initializeApp(firebaseConfig);

export const auth = getAuth(app);

La getApps().length protección devuelve la aplicación existente cuando ya hay una registrada, por lo que React Fast Refresh en next dev no genera un error de aplicación duplicada.

Cualquier componente que importe auth desde este archivo ahora tiene una instancia de Firebase Auth configurada que apunta a tu proyecto.

4. Verifica los tokens de ID de Firebase en un controlador de rutas de sesión

Crea un verificador de tokens compartido y un controlador de rutas de sesión que acepte un token solo después de verificarlo, y luego guárdalo en una cookie httpOnly .

Los documentos de verificación de tokens de ID de Firebase establecen la lista completa de notificaciones: una firma RS256 de las claves de firma actuales de Google, un emisor de https://securetoken.google.com/<projectId>, una audiencia igual al ID del proyecto, un sub no vacío, y exp y iat en la dirección correcta. jose aplica exp y iat por ti; el resto se pasan explícitamente a continuación.

Un detalle a tener en cuenta si abres esa página: apunta a la URL del certificado x509 de Google, lo cual es útil para las bibliotecas que analizan certificados. Google publica las mismas claves en formato JWK en la ruta service_accounts/v1/jwk , y ese es el formato que createRemoteJWKSet consume.

Módulo verificador de tokens

El verificador reside en un único módulo que importan tanto el controlador de rutas como el middleware:

import { createRemoteJWKSet, jwtVerify } from 'jose';

const projectId = process.env.NEXT_PUBLIC_FIREBASE_PROJECT_ID!;

const googleKeys = createRemoteJWKSet(
  new URL(
    'https://www.googleapis.com/service_accounts/v1/jwk/securetoken@system.gserviceaccount.com'
  )
);

export async function verifyFirebaseToken(idToken: string) {
  const { payload } = await jwtVerify(idToken, googleKeys, {
    algorithms: ['RS256'],
    issuer: `https://securetoken.google.com/${projectId}`,
    audience: projectId,
  });

  if (!payload.sub) {
    throw new Error('Token has no subject');
  }

  return payload;
}

createRemoteJWKSet obtiene las claves de firma de Google en el primer uso y las almacena en caché, de modo que el middleware de rutas protegidas no tenga que consultar a Google en cada solicitud.

La sub notificación es el ID de usuario de Firebase, que es lo que buscarías en tus propios datos si más adelante añades roles o estados de suscripción.

Controlador de rutas de sesión

Ahora crea el controlador de rutas en app/api/session/route.ts:

import { NextResponse } from 'next/server';
import { verifyFirebaseToken } from '@/lib/verify-token';

const COOKIE_NAME = 'member_session';

export async function POST(request: Request) {
  const body = await request.json().catch(() => null);
  const idToken = body?.idToken;

  if (typeof idToken !== 'string') {
    return NextResponse.json({ error: 'Missing idToken' }, { status: 400 });
  }

  try {
    const payload = await verifyFirebaseToken(idToken);
    const response = NextResponse.json({ uid: payload.sub });

    response.cookies.set(COOKIE_NAME, idToken, {
      httpOnly: true,
      secure: true,
      sameSite: 'lax',
      path: process.env.NEXT_PUBLIC_BASE_PATH || '/',
      maxAge: 60 * 60,
    });

    return response;
  } catch {
    return NextResponse.json({ error: 'Invalid token' }, { status: 401 });
  }
}

export async function DELETE() {
  const response = NextResponse.json({ ok: true });
  response.cookies.delete(COOKIE_NAME);
  return response;
}

Omite export const runtime = 'edge', aunque la guía de Webflow Cloud indique añadirlo a las rutas de API. La palabra "edge" cumple dos funciones: Webflow Cloud ejecuta tu aplicación en Cloudflare Workers, una plataforma perimetral, mientras que el destino de tiempo de ejecución edge de Next.js es una opción de compilación independiente que el adaptador OpenNext de Cloudflare no admite.

La directiva genera una compilación defectuosa; la plataforma ya se ejecuta en el borde.

El maxAge coincide con la duración del token de ID documentada, por lo que la cookie y el token caducan al mismo tiempo. Tras el despliegue, una POST a /members/api/session con un token no válido devuelve un cuerpo JSON 401, lo que confirma que el verificador está conectado.

5. Crea la página de inicio de sesión y envía el token a la ruta de sesión

Crea la página de inicio de sesión, autentica al miembro con el SDK de cliente de Firebase, lee el token de ID y envíalo a la ruta de sesión montada a través de NEXT_PUBLIC_BASE_PATH. La solicitud de sesión necesita el prefijo de ruta de la aplicación montada porque las llamadas fetch del lado del cliente deben incluir manualmente la ruta base.

Aquí tienes app/login/page.tsx al completo:

'use client';

import { useState } from 'react';
import { useRouter } from 'next/navigation';
import { signInWithEmailAndPassword } from 'firebase/auth';
import { auth } from '@/lib/firebase-client';

const basePath = process.env.NEXT_PUBLIC_BASE_PATH ?? '';

export default function LoginPage() {
  const router = useRouter();
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');
  const [error, setError] = useState<string | null>(null);

  async function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
    event.preventDefault();
    setError(null);

    try {
      const credential = await signInWithEmailAndPassword(auth, email, password);
      const idToken = await credential.user.getIdToken();

      const response = await fetch(`${basePath}/api/session`, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ idToken }),
      });

      if (!response.ok) {
        throw new Error('Session could not be created');
      }

      router.push('/dashboard');
    } catch (err) {
      setError(err instanceof Error ? err.message : 'Sign-in failed');
    }
  }

  return (
    <form onSubmit={handleSubmit}>
      <label>
        Email
        <input
          type="email"
          value={email}
          onChange={(e) => setEmail(e.target.value)}
          required
        />
      </label>
      <label>
        Password
        <input
          type="password"
          value={password}
          onChange={(e) => setPassword(e.target.value)}
          required
        />
      </label>
      <button type="submit">Sign in</button>
      {error && <p role="alert">{error}</p>}
    </form>
  );
}

La página llama a getIdToken() inmediatamente después de iniciar sesión, por lo que el valor enviado al servidor está actualizado. router.push('/dashboard') se resuelve en /members/dashboard sin que tengas que añadir ningún prefijo, ya que el enrutador lleva el basePath del momento de la compilación.

El token de ID del navegador y la cookie deben permanecer sincronizados, o los miembros perderán el acceso cuando el token actual caduque.

Sincronización de la sesión entre cliente y servidor

Añade un pequeño componente de cliente en components/session-sync.tsx y renderízalo en app/layout.tsx:

'use client';

import { useEffect } from 'react';
import { onIdTokenChanged } from 'firebase/auth';
import { auth } from '@/lib/firebase-client';

const basePath = process.env.NEXT_PUBLIC_BASE_PATH ?? '';

export function SessionSync() {
  useEffect(() => {
    return onIdTokenChanged(auth, async (user) => {
      if (!user) return;
      const idToken = await user.getIdToken();
      await fetch(`${basePath}/api/session`, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ idToken }),
      });
    });
  }, []);

  return null;
}

onIdTokenChanged se activa siempre que Firebase rota el token, y cada rotación vuelve a enviar el token a la ruta de sesión, lo que sobrescribe la cookie con una nueva.

Crea un app/dashboard/page.tsx de marcador de posición con cualquier contenido, despliégalo e inicia sesión con tu usuario de prueba: el navegador debería aterrizar en /members/dashboard con una cookie member_session visible en las Herramientas para desarrolladores, en Aplicación y luego en Cookies.

6. Protege las páginas de miembros con middleware.ts

Guarda el protector de rutas como middleware.ts en la raíz del proyecto para que una cookie de sesión caducada o ausente redirija antes de que se renderice una página protegida. La guía de personalización del framework de Webflow Cloud indica que el middleware de tiempo de ejecución de Node.js no es compatible y que solo el middleware de tiempo de ejecución Edge funciona en el entorno de ejecución de Workers.

Las versiones más recientes de Next.js renombran el middleware a proxy.ts, pero proxy se ejecuta en el entorno de ejecución de Node y no puede optar por Edge, por lo que un archivo renombrado no funcionará.

Guarda esto como middleware.ts junto a tu directorio app:

import { NextResponse, type NextRequest } from 'next/server';
import { verifyFirebaseToken } from '@/lib/verify-token';

const COOKIE_NAME = 'member_session';

function redirectToLogin(request: NextRequest) {
  const url = request.nextUrl.clone();
  url.pathname = '/login';
  url.searchParams.set('next', request.nextUrl.pathname);
  const response = NextResponse.redirect(url);
  response.cookies.delete(COOKIE_NAME);
  return response;
}

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

  if (!token) {
    return redirectToLogin(request);
  }

  try {
    await verifyFirebaseToken(token);
    return NextResponse.next();
  } catch {
    return redirectToLogin(request);
  }
}

export const config = {
  matcher: ['/dashboard/:path*', '/account/:path*'],
};

Clonar request.nextUrl y establecer pathname mantiene el basePath inyectado en la redirección. El destino resultante es /members/login. El comparador solo enumera las rutas de los miembros; /login y /api/session permanecen abiertas, lo que permite que un navegador no autenticado acceda al formulario de inicio de sesión y envíe un token.

Gestión de cookies durante fallos de verificación

Eliminar la cookie cuando falla la verificación es más importante de lo que parece. Una cookie obsoleta que permanezca ahí enviaría al miembro a un bucle de redirección entre una solicitud rechazada del panel de control y una página de inicio de sesión que cree que todavía están conectados.

Límites de seguridad de este flujo de sesión:

• POST de sesión: Autentica solo la identidad; los roles, planes, suscripciones y la propiedad requieren una autorización por separado, y carece de limitación de tasa, controles de gasto, tokens CSRF y validación de origen.
• Sesión DELETE: Elimina la cookie del navegador que realiza la solicitud sin verificación de token ni comprobaciones a nivel de recurso; además, carece de limitación de tasa, controles de gasto, protección CSRF y validación de origen.
• Middleware de ruta: Omite las búsquedas independientes de tokens revocados y usuarios deshabilitados; debes verificar roles, planes, suscripciones, propiedad y otros derechos antes de conceder acceso a contenido de pago o específico para el usuario.
• Flujo de inicio de sesión: La aplicación no tiene límite de tasa de inicio de sesión ni control de abusos; la httpOnly cookie bloquea la lectura directa de tokens, pero los scripts del mismo origen pueden realizar solicitudes autenticadas.

Ahora deberías entender qué protecciones proporciona este flujo de autenticación y qué protecciones de autorización, control de abusos y puntos finales requieren una implementación por separado.

No se incluye ninguna acción de cierre de sesión del cliente. Si Firebase permanece conectado, SessionSync puede publicar otro token y recrear una cookie eliminada, por lo que un flujo de cierre de sesión completo debe finalizar la sesión del cliente de Firebase antes de eliminar la cookie del servidor.

Despliega y abre /members/dashboard en una ventana privada: deberías ser redirigido a /members/login?next=%2Fdashboard. Inicia sesión y el panel se mostrará. Elimina la cookie en las Herramientas para desarrolladores y recarga para volver a la página de inicio de sesión.

¿Qué causa que la autenticación de Firebase falle en Webflow Cloud?

La autenticación de Firebase suele fallar aquí debido a un dominio no autorizado, una directiva de tiempo de ejecución incompatible, una ruta base montada faltante o un token de navegador que no se sincronizó en una cookie de sesión nueva.

Relaciona el síntoma visible con las entradas a continuación y luego inspecciona el ajuste de Firebase, Webflow Cloud, red o cookie mencionado.

Firebase devuelve auth/unauthorized-domain después de añadir el inicio de sesión con proveedor

Causa: El nombre de host actual del navegador no aparece en la lista de dominios autorizados de Firebase Authentication. Ten en cuenta que esto no puede ocurrir en el flujo de correo electrónico y contraseña creado anteriormente; el SDK solo genera este código desde la ventana emergente de OAuth y la ruta de redirección, y su mensaje lo indica: "Este dominio no está autorizado para operaciones OAuth para tu proyecto de Firebase". Por lo tanto, el desencadenante es casi siempre el cambio a Google u otro proveedor.

También aparece después de pasar de un dominio de prueba a un dominio personalizado, porque el primer nombre de host se autorizó durante la configuración y el reemplazo no. El fallo ocurre antes de que la aplicación montada pueda crear una sesión, por lo que inspeccionar el controlador de ruta o el middleware no revelará la discrepancia.

Confirma el nombre de host exacto en el navegador en lugar de confiar en el nombre del sitio o del proyecto.

Solución: Abre Authentication en la consola de Firebase, selecciona Settings y compara la lista de dominios autorizados con el nombre de host exacto del navegador. Añade el dominio de prueba que utilizas actualmente y el dominio personalizado que servirá al área de miembros. Corrige cualquier error ortográfico o discrepancia en el nombre de host, guarda la configuración, recarga la página de inicio de sesión y vuelve a intentarlo.

Un intento exitoso debería superar el inicio de sesión de Firebase y enviar el token de ID a /members/api/session.

El despliegue falla después de añadir export const runtime = 'edge' a la ruta de sesión

Causa: El despliegue está compilando una directiva de tiempo de ejecución de Next.js que el adaptador OpenNext de Cloudflare no admite. La terminología puede llevar a confusión porque Webflow Cloud se ejecuta en Cloudflare Workers, que es una plataforma edge, mientras que el objetivo de tiempo de ejecución edge de Next.js es una opción de compilación independiente.

La aplicación ya se despliega en Workers sin esa exportación, por lo que añadirla a un controlador de ruta o página crea un conflicto de compilación en lugar de habilitar el tiempo de ejecución de la plataforma.

Solución: Elimina export const runtime = 'edge' de todos los controladores de ruta y páginas, confirma el cambio y vuelve a desplegar. Si la salida de la compilación también menciona node:fs, inspecciona las dependencias añadidas al proyecto. Workers no tiene sistema de archivos, y la tabla de compatibilidad de Node.js de Webflow enumera fs bajo "Sin acceso al sistema de archivos; utiliza almacenamiento externo".

La ruta de sesión debe depender de paquetes compatibles con Web Crypto, como jose y dejar que Webflow Cloud proporcione el tiempo de ejecución de Workers.

POST /api/session devuelve un error 404

Causa: El navegador llamó a la ruta de la API sin el prefijo de montaje de la aplicación. Webflow Cloud inyecta la ruta de montaje para la aplicación desplegada, pero las llamadas del lado del cliente deben incluir ese prefijo manualmente./membersfetch

El problema puede pasar desapercibido durante el desarrollo local porque no existe una ruta de montaje. En la pestaña Red, una solicitud a /api/session en lugar de /ruta-de-montaje/api/session confirma que al paquete del cliente le falta el valor de la ruta base esperado.next dev/api/session/members/api/session

Solución: Compara la solicitud de inicio de sesión y la solicitud de sesión con la construcción esperada ${basePath}/api/session. Confirma que NEXT_PUBLIC_BASE_PATH esté configurado correctamente en el entorno de Webflow Cloud.SessionSyncfetch()NEXT_PUBLIC_BASE_PATH/members

Como esta variable pública se lee durante la compilación, vuelve a desplegar después de añadirla o modificarla. El siguiente inicio de sesión o actualización de token debería enviar la solicitud bajo la ruta montada y llegar al gestor de rutas.

Los miembros son redirigidos al inicio de sesión cuando el token de Firebase caduca

Causa: Firebase actualizó el token de ID del navegador, pero la cookie todavía contiene el valor caducado. El middleware verifica la cookie antes de renderizar una página protegida, por lo que rechaza el token obsoleto, elimina la cookie y redirige al miembro a la ruta de inicio de sesión.member_session

Esto suele significar que el listener de Firebase falta en el cliente, no se ejecutó, o su solicitud del lado del cliente no llegó al endpoint de sesión montado.SessionSyncapp/layout.tsx

Solución: Mantén el panel abierto hasta que el token rote y usa la pestaña Red para observar una nueva solicitud POST a /api/session. Confirma que el cliente recibe un usuario autenticado, llama a la función de inicio de sesión y envía la solicitud a través de la ruta correcta.POST/members/api/sessiononIdTokenChangedgetIdToken()NEXT_PUBLIC_BASE_PATH

Inspecciona la cookie después para verificar que la ruta de sesión la sobrescribió. Mantener la sesión iniciada tras reiniciar el navegador más allá de la vida útil del token requiere una sesión gestionada por el servidor con su propio almacenamiento, algo que esta versión no incluye deliberadamente.

Qué puedes construir a continuación con Firebase y Webflow

Una vez que un miembro puede iniciar sesión con Firebase Authentication en tu sitio de Webflow y el servidor lo valida, el resto de un producto de membresía son datos vinculados a ese usuario verificado: un documento de Firestore por miembro que contiene el estado del plan, y un gestor de rutas que lo lee antes de mostrar contenido de pago. Un webhook de tu proveedor de facturación es lo que cambia el estado cuando se modifica una suscripción.sub

Si los miembros necesitan diferentes niveles de acceso en lugar de un solo filtro, copia el patrón de acceso basado en roles. Sin embargo, yo añadiría primero el inicio de sesión con proveedores, ya que es la extensión más sencilla.