Cuando el alias del correo rompe el inicio de sesión
Diseñar el login de un sistema pareciera lo más resuelto de todo el desarrollo web: usuario, contraseña, listo. La parte que casi nadie cuestiona hasta que falla es una decisión que parece trivial: usar el correo electrónico como identificador único de cada cuenta.
El incidente
En uno de los paneles administrativos que administro, la cuenta de
administrador estaba identificada por una variable con el correo exacto
del dueño. Un día, ese mismo administrador inició sesión usando un
alias de su propio correo —del tipo
nombre+algo@gmail.com, una función real de Gmail que trata
ese alias como una bandeja distinta pero entrega en la misma cuenta— y
el sistema no lo reconoció como el mismo administrador de siempre. Para
el sistema, ese alias era, técnicamente, un correo distinto al que
tenía guardado.
Por qué el correo es una mala llave primaria
El correo electrónico no es tan estable como parece. Además de los alias con "+" de Gmail, hay proveedores que ignoran los puntos dentro del nombre de usuario, dominios que cambian de mayúsculas a minúsculas de forma inconsistente entre formularios, y personas que simplemente tienen más de una dirección y no recuerdan con cuál se registraron. Usar el correo como identificador único de la cuenta ata la identidad de un usuario a algo que ni el propio proveedor de correo garantiza que sea una sola cadena de texto estable.
La solución: separar identidad de contacto
La corrección no es complicada, pero hay que decidirla desde el
principio del diseño de la base de datos: una columna
usuario —un identificador elegido por la persona, estable,
que no cambia aunque cambie de correo— separada de la columna
correo, que sirve solo para contacto y recuperación de
contraseña, no para iniciar sesión ni para comparaciones de identidad
en el código. El login se hace contra el nombre de usuario; el correo
queda libre para reenviar notificaciones o restablecer una contraseña
sin arrastrar el problema de los alias.
Por qué esto cambia el diseño desde el primer día
Agregar esta columna después, cuando el sistema ya tiene usuarios reales identificados por su correo en decenas de tablas relacionadas, es mucho más caro que decidirlo antes de la primera migración. Por eso, desde este incidente, cualquier sistema nuevo que diseño —sin importar lo simple que parezca su panel de administración— separa estas dos columnas desde el esquema inicial, aunque al principio ambas tengan el mismo valor. El costo de la columna de más es mínimo; el costo de migrarla después, con usuarios activos y datos relacionados, no lo es.