Configurar reglas de Firestore basadas en custom claims te permite filtrar datos por usuario sin exponer toda tu colección al público. Aprenderás a integrar Firebase Authentication con un custom token, aplicar condicionales where en tus queries y blindar tu base de datos antes de salir a producción. Ideal si ya trabajas con Next.js, Firebase y manejas roles por usuario.

Cómo activo el módulo de autenticación anónima en Firebase

Antes de autenticarte con un custom token, necesitas habilitar el método de login anónimo desde la consola de Firebase. Ve a la sección de Authentication, ubica la opción Anónimo, dale Habilitar y guarda. Con eso queda listo el módulo para recibir sesiones generadas desde tu propio backend [00:14].

¿Para qué sirve el login anónimo si voy a usar custom token? Es el método base que Firebase necesita activo para aceptar sesiones creadas con signInWithCustomToken. No significa que tus usuarios entren sin credenciales.

Cómo conecto signInWithCustomToken con mi hook de películas

En tu archivo firebase/index.js importa y exporta dos métodos nuevos: getAuth y signInWithCustomToken. Centralizar estos exports te ahorra fricción cuando los uses en hooks o componentes [00:38].

Luego, en hooks/useMovies, actualiza el query para que primero pida el token y los user claims a tu API:

• Haz fetch a tu endpoint que retorna el Firebase token.
• Parsea la respuesta a JSON para extraer token y claims.
• Llama signInWithCustomToken(auth, token) para abrir la sesión con esos claims.
• Importa también el método where de Firestore para construir el condicional.

Esa llamada crea una nueva sesión del usuario cargando los claims que firmaste en tu route API. A partir de ahí, los claims viajan con cada request a Firestore [01:30].

Cómo uso where para filtrar por género

Dentro del query de películas, agrega una sentencia where que filtre solo los documentos cuyo género coincida con alguno de los géneros incluidos en los claims del usuario. Si el usuario tiene horror y thriller, verá ambos. Si solo tiene uno, verá solo ese subconjunto.

Por qué debo modificar las reglas de Firestore en producción

Las reglas de Firestore son la capa de seguridad que decide qué requests pueden leer o escribir en tu base de datos. Si las dejas con true quemado, cualquiera con tu config puede leer todo. Eso funciona para pruebas, pero es un riesgo real al publicar [02:40].

¿Qué son los custom claims en Firebase? Son atributos personalizados que firmas dentro del token del usuario, como roles o permisos. Las reglas de Firestore pueden leerlos y filtrar el acceso sin depender solo del UID.

Cómo escribo la regla con hasAny y request.auth.token

En la pestaña Rules de Firestore, ajusta el match para que apunte directamente a la colección movies en vez de un comodín. Dentro, define solo el permiso de lectura ya que estás trabajando con datos de prueba.

El condicional revisa que el request.auth.token tenga un atributo de géneros y que ese arreglo haga match con los géneros permitidos usando la función hasAny. Le pasas un array como ['horror', 'thriller'] y Firestore deja pasar el request solo si hay coincidencia [03:20].

De esta forma, la regla aplica únicamente a la colección de películas. Como no tienes otras colecciones activas, no necesitas reglas adicionales todavía.

Cómo pruebo que las reglas funcionan con distintos usuarios

Levanta el servidor y refresca la app. Con un usuario que tiene ambos roles, vas a ver tanto las películas de horror como las de thriller. Hasta ahí todo bien, pero la prueba real está en usuarios con un solo rol.

Inicia sesión con la cuenta que solo tiene el claim de horror. Como activaste multifactor authentication en clases anteriores, valida con tu llave de seguridad. Vas a notar que la sección de thriller aparece vacía y la de horror carga normal [05:00].

Cómo añado un componente Empty para estados sin datos

Una sección vacía sin feedback se ve rota. Para evitarlo, crea un componente Empty que reciba una prop show:

• Si show es true, renderiza un párrafo con el mensaje There are no movies at this time.
• Si es false, retorna null.
• Úsalo en tu componente de tabs evaluando si length === 0 para cada listado.

Guarda y vuelve a probar. Ahora cuando entres con el usuario de thriller, vas a ver el estado empty unos instantes mientras carga, después aparecen las películas correctas y la pestaña de horror queda con el mensaje vacío. Funciona al revés con el otro usuario.

Qué reto debo resolver con Supabase y Auth0

Replica esta misma arquitectura usando Supabase Auth con Auth0. En la clase pasada armaste el diagrama, ahora llévalo a una implementación real: genera un token desde Auth0, intercámbialo por una sesión en Supabase y aplica Row Level Security basada en claims, igual que hiciste aquí con Firestore.

Cuéntame en los comentarios qué dificultades encontraste al traducir el flujo de Firebase a Supabase.