Changelogs
web-next: herramientas de PD (transferir, comercio, códigos de promoción)
14 de julio de 2026 a las 09:27adevopg · 66d056c
- /transfer-d-points: transferir PD a la cuenta dueña de un personaje (requiere token de seguridad; movimiento atómico con FOR UPDATE). - /trade-points: comercio PD<->oro mediante códigos de 1 solo uso (contraseña + token + Turnstile; oro al creador por SOAP; expira 1h; lock de 5s tras canjear; rollback total si falla la entrega). - /promo-code: canje de códigos por PD/PV (sensibles a mayúsculas/minúsculas, usos limitados, 1 canje por cuenta). - /admin/promo: panel para crear / editar / activar / desactivar / borrar códigos de promoción. - Tablas nuevas (sql/): home_tradecode, home_promocode, home_promoredemption.
BD: eliminar FK obsoleta home_securitytoken.user_id -> auth_user
13 de julio de 2026 a las 21:42adevopg · 22ae0ee
Bloqueaba /api/account/security-token (HTTP 500) y, por tanto, la activación de 2FA. Las tablas home_* usan el id de cuenta de AzerothCore, no auth_user (vacío tras la migración de Django). Aplicado en producción.
Añadir ruta /security-2falogin (verificación en 2 pasos / TOTP)
13 de julio de 2026 a las 21:37adevopg · 4e089b5
Activación de 2FA (TOTP) para el login del juego, guardando el secreto en acore_auth.account.totp_secret tal como lo lee el bnetserver 3.4.3. - lib/two-factor.ts: TOTP (HMAC-SHA1, 30s, 6 dígitos, ±1) idéntico al core (verificado contra los vectores RFC 6238), Base32, otpauth, y codificado del secreto: crudo por defecto o AES-128-GCM (ciphertext‖IV12‖tag12) si se define TOTP_MASTER_SECRET (mismo hex que TOTPMasterSecret del servidor). - Flujo seguro sin bloqueos: el secreto se genera y queda PENDIENTE en la sesión; sólo se escribe en la cuenta tras verificar un código válido. - /api/account/2fa: activar (password + token de seguridad), verificar y desactivar (con código actual). QR generado en el servidor (el secreto no sale a terceros). - Página + componente fieles al markup (preview, pasos, copiar clave, ojos). Verificado E2E: activar -> QR/secreto -> verificar -> totp_secret = 20 bytes (igual al secreto escaneado) -> desactivar -> NULL.
d-points: reconciliación SumUp (sin webhooks) para asegurar la entrega de PD
13 de julio de 2026 a las 20:22adevopg · 42fc15d
SumUp eliminó los webhooks, así que la acreditación no puede depender de que el navegador vuelva al return_url. Se añade reconciliación consultando el estado en la API de SumUp de los checkouts pendientes (fulfilled=0): - reconcileSumUpCheckouts() en lib/sumup.ts: recorre los pendientes recientes y acredita los que estén PAID (reclamo atómico idempotente). - /d-points y /account reconcilian los pendientes de la cuenta al cargar, para reflejar el saldo aunque el usuario no pasara por la página de éxito. - /api/dpoints/reconcile: backstop global protegido con CRON_SECRET, pensado para un systemd timer que lo llame periódicamente. Verificado E2E con tarjeta de test: pago SumUp sin volver a la web -> el backstop acredita los PD (idempotente). Credenciales y CRON_SECRET viven en .env.local (fuera de git).
d-points: arreglar iconos de los botones de método (Stripe/SumUp)
13 de julio de 2026 a las 17:56adevopg · 6222a46
Los SVG no tenían tamaño intrínseco y se renderizaban enormes encima del texto. Se porta el layout flex de .dnt-methods del tema original y se dimensionan los iconos (22px, en línea con el texto) igual que se veía PayPal. Los SVG llevan ahora width/height explícitos. Verificado además el flujo Stripe de extremo a extremo (tarjeta de prueba 4242): pago -> página de éxito -> 100 PD acreditados por €1 con reclamo atómico idempotente. Datos de prueba restaurados tras la verificación.