NovaWoW/docs/MIGRACION_3.4.3.md

Migración del portal 3.3.5a → 3.4.3 (cuentas Battle.net)

Este documento describe los cambios hechos para adaptar el portal (antes AzerothCore 3.3.5a) a un servidor TrinityCore 3.4.3 con cuentas Battle.net (login por email + cuentas de juego + selector).

Resumen del cambio de modelo

Concepto	3.3.5a (antes)	3.4.3 (ahora)
Login	username en account	email en battlenet_accounts
Contraseña	SRP6 Grunt (SHA1)	SRP6 v2 (PBKDF2-HMAC-SHA512) para bnet
Cuenta de juego	la propia account	1..N filas en account enlazadas por battlenet_account + battlenet_index
Nombre de cuenta de juego	elegido por el usuario	generado: <bnetId>#<index> (p.ej. 5#1)
Selector	—	sí, si la cuenta bnet tiene varias cuentas de juego

Un registro crea dos filas: una en battlenet_accounts y otra en account.

Algoritmos SRP6 (home/bnet.py)

• battlenet_accounts (SRP6 v2) — replica BnetSRP6v2<SHA256> del source:
  • N de 2048 bits, g = 2, salt de 32 bytes.
  • usuario SRP = HEX(SHA256(UPPER(email))).
  • x = PBKDF2-HMAC-SHA512(usuario + ":" + password, salt, 15000, 64), con ajuste del bit alto y x %= (N-1).
  • verifier = g^x mod N, almacenado en little-endian de longitud mínima.
  • srp_version = 2, email en MAYÚSCULAS.
• account (SRP6 Grunt/SHA1) — el clásico de 3.3.5a, reutilizado para la cuenta de juego. Username <bnetId>#<index> y password (16, mayúsculas).

⚠️ Verificación pendiente (requiere el servidor real): el orden de bytes del verifier de bnet se ha fijado a little-endian según el source. El login del PORTAL funciona siempre (registra y verifica igual). Para confirmar que el CLIENTE 3.4.3 puede conectar con una cuenta creada por el portal, crea una cuenta desde la web y prueba a entrar en el juego. Si fallara, cambia _BNET_VERIFIER_LITTLE_ENDIAN = False en home/bnet.py. Alternativa: compara los bytes de salt/verifier de una cuenta creada con .bnetaccount create frente a una creada por el portal con el mismo email+password.

Cambios en el código

• home/bnet.py (NUEVO): SRP6 v2 + Grunt y helpers bnet↔cuentas de juego.
• home/views.py:
  • login_view: login por email contra battlenet_accounts; resuelve las cuentas de juego (autoselecciona si hay una, deja pendiente si hay varias).
  • select_account_view (NUEVO) + auth/select_account.html: selector.
  • my_account: si hay login bnet sin cuenta de juego elegida → selector.
  • register_view / activate_account_view: crean bnet + cuenta de juego.
  • change_password_view: cambia la contraseña en battlenet_accounts.
  • change_email_view / confirm_new_email_view: cambian el email en battlenet_accounts recalculando salt/verifier (dependen del email).
  • logout_view: limpia username, account_id, bnet_id, bnet_email.
• home/models.py: AccountActivation con username/salt/verifier opcionales (la identidad es el email). Migración 0012_*.
• Plantillas: partials/login.html (campo email) y partials/register.html (registro por email, sin username).

Sesión

Tras elegir cuenta de juego se guardan en sesión, igual que antes: request.session['username'] (= <bnetId>#<index>) y account_id. Por eso las ~60 vistas de tienda/personajes/puntos siguen funcionando sin cambios. Además se guardan bnet_id y bnet_email para cambios de contraseña/email.

Requisitos de esquema (BD auth)

• battlenet_accounts: id, email, srp_version, salt, verifier, ... (columnas base de TrinityCore). Custom del source: battletag, trial_expiry, tournament_expiry, game_time_expiry, battlePayCredits, voteCredits.
• account: debe tener battlenet_account y battlenet_index (además de username, salt, verifier, email, reg_mail, expansion, recruiter, ...).

Pasos para desplegar

1. Aplicar la migración del portal:

   python manage.py migrate home
   

2. Apuntar DB_NAME_AUTH al auth del servidor 3.4.3.
3. Registrar una cuenta desde la web y comprobar el email de activación.
4. Activar y probar login en el cliente 3.4.3 (ver nota de verificación).

Battlepay / SumUp (tienda del cliente)

Integración de la tienda nativa del cliente (Battlepay) con la pasarela SumUp, usando las tablas battlepay_orders / battlepay_price del source (sql/battlepay_sumup.sql, aplicar sobre la BD auth).

Flujo:

1. En el juego, el jugador pulsa Comprar; si el producto tiene precio en battlepay_price, el worldserver crea una orden PENDING en battlepay_orders (con account_id = id de cuenta de juego y una reference única).
2. En la web, /es/battlepay/ lista las órdenes PENDING de la cuenta de juego seleccionada y permite pagarlas.
3. /es/battlepay/pay/ crea un checkout de SumUp usando la reference de la orden como checkout_reference.
4. El webhook /es/sumup-webhook/ marca la orden como PAID (paid_at = UNIX_TIMESTAMP()), validando el estado contra la API de SumUp si hace falta.
5. El worldserver entrega el producto y marca la orden DELIVERED.

Código: home/pagos_sumup.py (crear_checkout_battlepay, obtener_checkout), vistas battlepay_view / battlepay_pay_view / sumup_webhook en home/views.py, plantillas account/battlepay.html y partials/pago_sumup.html.

Nota: battlepay_orders.account_id es el id de cuenta de juego (account.id), mientras que battlePayCredits (créditos del sistema clásico de puntos) vive en la cuenta bnet (battlenet_accounts.id); se unen por account.battlenet_account. Esta pasarela usa las órdenes en €, no los créditos.

Configuración necesaria:

• Aplicar sql/battlepay_sumup.sql en la BD auth y rellenar battlepay_price con tus product_id reales.
• Configurar el webhook de SumUp apuntando a https://<tu-dominio>/es/sumup-webhook/.
• Enlazar /es/battlepay/ desde el menú de «Mi cuenta» (opcional).

Pendiente / opcional

• Mostrar el email (en lugar de <bnetId>#1) como nombre visible en «Mi cuenta» es un retoque cosmético opcional.