NightSpire/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).

Pendiente / opcional

• Battlepay/SumUp: el source trae battlePayCredits (en battlenet_accounts) y las tablas battlepay_orders / battlepay_price (sql/custom/battlepay_sumup.sql). Ojo: battlepay_orders.account_id es el id de cuenta de juego (account.id), mientras que battlePayCredits está en la cuenta bnet (battlenet_accounts.id); se unen por account.battlenet_account. La integración de la pasarela con estas tablas se puede abordar como paso siguiente.
• Mostrar el email (en lugar de <bnetId>#1) como nombre visible en «Mi cuenta» es un retoque cosmético opcional.