Changelogs
Aceptar el correo en MAYÚSCULAS y mostrar las cuentas como WOW1, no 17#1
15 de julio de 2026 a las 18:53adevopg · c255724
Dos fallos que se juntaban justo en «recuperar nombre de cuenta»: - La validación de Gmail era sensible a mayúsculas (`/@gmail\.com$/` sin la `i`), así que NOVAWOW86@GMAIL.COM se rechazaba con invalidEmail. Y desde que los correos muestran la cuenta en MAYÚSCULAS, quien la copiara de ahí y la pegara no podía recuperar la cuenta, ni registrarse, ni cambiar el correo: la misma regex estaba repetida en register/change-email/recover. Ahora es una sola, con la `i`, en lib/bnet.ts (junto a normalizeEmail). El dominio de un correo NO distingue mayúsculas. - Los correos enseñaban el username interno («17#1»), que no le dice nada a nadie, en vez del nombre visible («WOW1»). Afectaba a DOS plantillas: la de nombres de cuenta y la de la lista de tokens. La conversión existía, pero como helper local de my-account; sube a lib/bnet.ts como `gameAccountDisplayName` (el inverso de `makeGameAccountUsername`) y la aplican las propias plantillas, para que ningún sitio que las use pueda olvidarse. Verificado: la regex acepta las 3 variantes de caja y sigue rechazando no-Gmail; los dos correos renderizados muestran «Cuenta: WOW1 / WOW2».
El correo sale en MAYÚSCULAS en los correos de token y activación
15 de julio de 2026 a las 18:40adevopg · edf1fee
- Token: el asunto era «Token de seguridad - NightSpire» a secas. El original decía «Token de seguridad de la cuenta {username} - {NOMBRE_SERVIDOR}»; la reescritura se dejó la cuenta por el camino. Ese correo sale de `session.bnetEmail`, que ya va normalizado, así que las MAYÚSCULAS son gratis. - Activación: asunto y cuerpo pasan a normalizar el correo, para que se vea igual que en el del token. El DESTINATARIO va sin normalizar: es la dirección tal cual la escribió el usuario. El correo de activación se manda desde DOS sitios: `registerAccount` y `recover.ts` (el reenvío del enlace, «no me llegó»). Se cambian los dos o saldría distinto según por dónde lo pidieras. Lo delató el build: /api/auth/activate cargaba un chunk y /api/auth/recover otro con la versión vieja.
El botón de solicitar token deja de quedarse bloqueado en «Token enviado»
15 de julio de 2026 a las 18:29adevopg · 653f7f0
Tras un envío correcto se ponía `sent` y el botón quedaba desactivado para siempre: no volvía a «Solicitar token» y, sobre todo, ya no podías pulsarlo para ver el aviso de «cada 7 días», que es la respuesta que hay que ver. Había que recargar la página para recuperarlo. Ese bloqueo no venía del original: la versión anterior (isla React) tenía `disabled={busy}` y nada más. Se vuelve a eso. La clave `sent` («Token enviado») queda sin uso y se borra de ES/EN. Verificado en producción: dos POST seguidos responden el cooldown, en vez de que el segundo fuera inalcanzable.
Arreglar cierre de sesión solo: <Link> prefetcheaba /log-out
15 de julio de 2026 a las 18:27adevopg · 61ca63a
Regresión del commit anterior. /log-out es un GET que destruye la sesión, y yo lo enlacé con <Link>: el router de Next lo prefetchea al entrar en pantalla, así que la cookie se borraba sin que nadie pulsara. La página se renderizaba en el servidor con la sesión («¡Ya estás conectado!») y al recargar ya no había sesión. Reproducido: una petición de prefetch (RSC: 1, Next-Router-Prefetch: 1) a /es/log-out responde `set-cookie: nightspire_session=; Max-Age=0`. Se enlaza con <a> plano, que es justo como lo hace SiteHeader. Queda comentado en ambos sitios para que no vuelva a colarse.
Log-in y crear cuenta: avisar si ya hay sesión en vez de ofrecer el formulario
15 de julio de 2026 a las 18:18adevopg · c46cea2
Ninguna de las dos miraba la sesión, así que quien ya estaba conectado veía el formulario de login o el de registro. Ahora, con `bnetId` en sesión (lo mismo que da por buena la sesión en el resto del sitio), sale «¡Ya estás conectado!» y un enlace a /log-out, como las plantillas del tema. En crear cuenta el cuadro informativo se mantiene: sigue explicando cómo son las cuentas aunque ya tengas sesión. Solo se sustituye el formulario. Las dos pasan a `force-dynamic`: leen cookies y no se pueden prerenderizar. Verificado en producción sellando una cookie de sesión real con iron-session: con sesión salen los dos avisos y desaparece el formulario; sin sesión el formulario sigue ahí y el aviso no se renderiza.