Cuentas de usuario y conexión

El mensaje que lo cambia todo

Una semana después de la puesta en línea, Tom recibe el comentario que más se repite. Lina, una alumna de 1.º de ESO, le escribe: «¡Profe, marqué todos mis hábitos en el ordenador de la biblioteca, y por la noche en mi teléfono había desaparecido todo!». Tom lo entiende de inmediato: había elegido el almacenamiento local en el capítulo 3, y localStorage guarda los datos en el navegador de cada dispositivo. El ordenador de la biblioteca y el teléfono de Lina son dos mundos separados que no se hablan. Para que la app siga a Lina a todas partes, debe poder reconocerla — y reconocer a alguien, en la web, se llama una cuenta de usuario.

Recuerda: en el capítulo 3, «cuenta de usuario» figuraba en la lista de palabras trampa a desterrar de tu v1. No era una prohibición definitiva, era una cuestión de timing. Tom primero construyó, desplegó, y recogió comentarios reales. Ahora, la necesidad ya no es una hipótesis: es la petición número uno de sus usuarios. Es exactamente el orden correcto — la complejidad se justifica por una necesidad probada, nunca por un «por si acaso». Vas a ver que esta complejidad, bien abordada, está totalmente a tu alcance.

Autenticación: lo que pasa de verdad

Tres palabras de vocabulario van a transformar tus diálogos con la IA sobre este tema. La autenticación es probar quién eres («soy de verdad lina@instituto.es»). La sesión es seguir siendo reconocido durante un tiempo sin tener que probarlo en cada clic — es ella la que hace que no tengas que reconectarte cada treinta segundos. La autorización es lo que tienes derecho a ver o hacer una vez reconocido («Lina ve SUS hábitos, no los de los demás»). Cuando uses estas palabras en tus prompts, la IA sabrá exactamente de qué hablas.

Detrás de una simple pantalla de conexión se esconde en realidad todo un sistema: el registro, la conexión, la desconexión, la recuperación en caso de olvido, la protección contra los robots, el almacenamiento seguro de las credenciales… Construir todo eso uno mismo es largo, y sobre todo peligroso: el mínimo error expone los datos de tus usuarios. La buena noticia es que hoy nadie lo construye por su cuenta — ni siquiera los profesionales. Todo el mundo se apoya en servicios especializados que han resuelto el problema de una vez por todas.

Los servicios de autenticación listos para usar

Estos servicios se llaman a veces BaaS (Backend as a Service): proporcionan a tu app los ladrillos de servidor que necesita — entre ellos la autenticación — sin que tengas que gestionar un servidor. Creas una cuenta con ellos, recuperas dos claves, y tu app les delega todo el trabajo sensible. Tres nombres aparecen por todas partes, y la IA los conoce de memoria:

Para este curso, seguiremos a Tom con Supabase: su oferta gratuita cubre de sobra una app de clase, y el hecho de tener la autenticación y la base de datos en el mismo sitio simplificará el capítulo 7. Pero retén el principio más que el nombre — el método que vas a aprender se aplica de forma idéntica en los competidores.

¿Qué método de conexión para tus usuarios?

Existen tres grandes formas de conectarse, y la buena elección depende por completo de quiénes son tus usuarios. La contraseña clásica es universal pero penosa: la gente la olvida, la reutiliza en todas partes, y hay que gestionar la recuperación. La conexión vía Google o Apple («OAuth») es cómoda… a condición de que tus usuarios tengan una cuenta de Google que usen de verdad. El enlace mágico (magic link) elimina directamente la contraseña: el usuario introduce su email, recibe un enlace, hace clic, y ya está conectado.

• Contraseña: universal, pero olvidos frecuentes y gestión de recuperación obligatoria.
• Conexión Google / Apple: un clic y listo — si tus usuarios tienen (y usan) esas cuentas.
• Enlace mágico: nada que recordar, nada que olvidar. Perfecto para usuarios ocasionales o jóvenes. Única exigencia: acceder a su buzón de correo.

Tom elige el enlace mágico: todos sus alumnos tienen una dirección proporcionada por el instituto, y «contraseña olvidada» se habría convertido en su segunda vida. Hazte la misma pregunta para tu propia app: ¿qué método crea menos fricción para TUS usuarios? No hay una respuesta buena universal, solo una respuesta buena para tu público.

sequenceDiagram
  participant E as Alumna
  participant A as App de Tom
  participant S as Servicio Supabase
  E->>A: Escribe su dirección de email
  A->>S: Solicita un enlace mágico
  S-->>E: Envía el email con el enlace
  E->>A: Hace clic en el enlace recibido
  A-->>E: Sesión abierta y hábitos mostrados

Integrar la autenticación con la IA

El proceso cabe en tres tiempos: crear tu proyecto en Supabase (una cuenta, un clic en «New project»), recuperar tus dos claves de acceso, y luego pedir a la IA que lo conecte todo. Como con el despliegue en el capítulo 5, no tienes que memorizar el procedimiento — pides una guía paso a paso adaptada a tu nivel. Este es el prompt completo de Tom:

Quiero añadir cuentas de usuario a mi app de seguimiento de hábitos.
Contexto: app HTML/CSS/JS desplegada en Vercel, datos en localStorage por ahora.
Usa Supabase Auth con conexión por enlace mágico, sin contraseña.
Lo que quiero:
1. una pantalla de conexión simple: campo de email + botón «recibir mi enlace»
2. tras hacer clic en el enlace recibido por email, el usuario vuelve a la app, conectado
3. un botón «cerrar sesión» discreto en la parte superior de la página
4. si el usuario no está conectado, ve la pantalla de conexión; si no, sus hábitos
IMPORTANTE: no toques todavía los datos — mantenemos localStorage por ahora.
Guíame primero para crear el proyecto Supabase y encontrar mis dos claves, paso a paso, antes de escribir una sola línea de código.

La línea «no toques todavía los datos» es estratégica. Añadir la autenticación Y migrar los datos al mismo tiempo son dos grandes cambios de golpe — exactamente lo que el capítulo 4 te enseñó a evitar. Este capítulo conecta el reconocimiento de los usuarios; el capítulo 7 se ocupará de sus datos. Un escalón a la vez, incluso cuando la escalera es grande.

Las claves de API: tus primeros secretos

Al crear tu proyecto Supabase, vas a encontrarte con dos claves. La clave pública (llamada «anon») identifica tu app: puede vivir en el código del navegador, está pensada para eso. La clave secreta (llamada «service_role») da TODOS los derechos sobre tu proyecto: no debe aparecer nunca, jamás, en código visible por un navegador. Estos secretos se guardan en un archivo especial, el .env, que Git ignora:

# Archivo .env — se queda en tu máquina, nunca se publica
SUPABASE_URL=https://tuproyecto.supabase.co
SUPABASE_ANON_KEY=eyJhbGciOiJIUzI1NiIs...   # pública: OK en el navegador
SUPABASE_SERVICE_ROLE_KEY=eyJzZXJ2aWNl...   # SECRETA: nunca en el navegador

Probar el flujo como un usuario

La autenticación se prueba de principio a fin, sin atajos: introduce una dirección real, ve a buscar el email (mira también en el spam, es el bloqueo clásico), haz clic en el enlace, verifica que llegas conectado. Luego desconéctate y vuelve a empezar. Por último, la prueba decisiva: abre la app en dos navegadores diferentes con dos direcciones diferentes, y verifica que cada uno tiene su propia sesión. Si algo falla, aplica el método del capítulo 4 — informe de bug en cuatro puntos. Aquí tienes la versión adaptada a la autenticación:

Bug de conexión a corregir.
Lo que hago: introduzco mi dirección, recibo el email del enlace mágico, hago clic en el enlace.
Lo que esperaba: volver a la app, conectado.
Lo que pasa: vuelvo a la app pero sigo viendo la pantalla de conexión.
Error en la consola: [pega aquí la línea roja exacta, si la hay]
Verifica en prioridad la configuración de las URL de redirección en Supabase — la URL de mi sitio desplegado es https://mi-app.vercel.app — y dime qué corregir, paso a paso.

Este prompt muestra un reflejo de nivel superior: Tom orienta el diagnóstico («verifica en prioridad las URL de redirección») porque es LA causa clásica de ese síntoma — el servicio devuelve al usuario hacia una dirección que no corresponde al sitio desplegado. No estás obligado a conocer esas causas clásicas: pregunta a la IA «¿cuáles son las tres causas más frecuentes de este problema?» y te las listará.

Lo que te espera en el próximo capítulo

Al final de esta etapa, la app de Tom reconoce a cada alumno… pero sus hábitos siguen viviendo en el localStorage de cada dispositivo. Lina puede conectarse en la biblioteca y en su teléfono, pero todavía no ve los mismos datos. Falta la segunda mitad de la solución: una base de datos en línea, donde los hábitos de cada cuenta se almacenarán de una vez por todas, accesibles desde cualquier sitio. Ese es todo el programa del capítulo 7 — y ya has puesto la base ideal para acogerla.