- Backend: helper verify_turnstile en _base (verifica el token contra
challenges.cloudflare.com/siteverify; fail-closed ante error de red; si no hay
secreto configurado, no bloquea). Se exige en el POST de login_view,
register_view y recover_account_view -> rechazo con mensaje si falla.
- settings: TURNSTILE_SITE_KEY / TURNSTILE_SECRET_KEY desde .env (el secreto NO
se commitea). La clave de sitio se expone a las plantillas por el context
processor (TURNSTILE_SITE_KEY).
- Frontend: hook useTurnstile (carga el script de Cloudflare una vez y renderiza
el widget, devuelve el token). LoginForm/RegisterForm/RecoverForm incluyen el
widget, mandan cf-turnstile-response y deshabilitan el submit hasta tener token.
El sitekey llega por data-sitekey en el div de montaje.
Verificado: sin token los 3 POST se rechazan; siteverify acepta la clave secreta
(error invalid-input-response con token falso, no invalid-input-secret).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
recover_account_view era un stub que solo renderizaba (los formularios no tenían
backend y el HTML arrastraba un reCAPTCHA de otro dominio). Ahora es funcional:
Backend:
- Modelo PasswordReset (token+email+expiración 1h) + migración 0014.
- recover_account_view maneja POST JSON con 3 tipos, todo por email (bnet), con
respuestas genéricas anti-enumeración:
* password: crea token y envía enlace de reset (emails/password_reset.html).
* accountname: envía las cuentas de juego ligadas (emails/account_names.html).
* activation: reenvía el enlace de activación pendiente (emails/activation.html).
- reset_password_view: GET valida el token (isla), POST re-deriva el verifier
SRP6 v2 de la cuenta bnet (bnet.bnet_make_registration) y lo actualiza; marca el
token usado. Ruta 'reset-password'.
- Resiliente si la BD de cuentas (AzerothCore) no está disponible: mensaje limpio,
nunca 500.
Frontend (islas Vite): RecoverForm.tsx (selector de tipo + email) y
ResetPassword.tsx (nueva contraseña con token). Se elimina el reCAPTCHA roto; se
puede añadir uno propio si se aportan claves.
Verificado en producción: los 3 flujos devuelven éxito genérico; reset valida
token y contraseñas; token válido no provoca 500.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El módulo monolítico (~3200 líneas) se convierte en un paquete cuyo
__init__.py re-exporta todas las vistas, de modo que `views.X`,
`from home.views import X` y la cadena 'home.views.not_found' (handler404)
siguen funcionando sin tocar urls.py.
Módulos por sección: _base (imports comunes + require_paid_stripe), auth,
pages, account, recruit, characters, store, points, guild, history,
players y payments. Cada submódulo hereda los imports con
`from ._base import *`; las dependencias entre secciones se resuelven con
imports explícitos (guild->auth, recruit/history->account).
Se eliminan dos definiciones duplicadas que quedaban muertas al cargar:
- get_character_image (primera copia, idéntica a la efectiva)
- store_novawow_success_view (stub sin SOAP, pisado por la versión real)
Validado con `manage.py check` (0 issues), resolución de las 100 rutas y
un chequeo estático de nombres no definidos por módulo.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Inna