0fef9ac35b
- pagos_sumup.py: crear_checkout_battlepay(reference,...) y obtener_checkout() - battlepay_view: lista las órdenes PENDING de la cuenta de juego - battlepay_pay_view: crea checkout SumUp para una orden concreta (checkout_reference=reference) - sumup_webhook: marca la orden PAID (valida estado contra la API de SumUp si falta) - plantillas account/battlepay.html y partials/pago_sumup.html - sql/battlepay_sumup.sql (tablas battlepay_orders/battlepay_price) y docs actualizados Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
123 lines
6.1 KiB
Markdown
123 lines
6.1 KiB
Markdown
# 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:
|
|
```bash
|
|
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.
|