Esta página aún no está traducida: se muestra la versión en inglés.

Auth & Players

El inicio de sesión es un paso que puedes sobrescribir, no una caja negra. Proveedores, sesiones, vinculación de identidades, baneos. Cada punto del flujo — antes y después del inicio de sesión, antes y después de vincular, antes y después de una fusión, al cambiar un estado — es un punto de extensión declarado, con un tipo declarado: un filtro, que puede rechazar el paso, o un observador, que no puede.

Cuándo usarlo

• Los jugadores (player) tienen que iniciar sesión con el dispositivo, email, Apple, Google, Steam o un proveedor propio. Crear al jugador en su primer inicio de sesión (sign-in) se activa con un flag, no con un segundo flujo.
• Una cuenta de invitado tiene que poder convertirse más adelante en una cuenta completa: Link agrega Steam sin perder el progreso, y una fusión (merge) reúne dos cuentas en un solo jugador.
• Las políticas tienen que ejecutarse donde nadie pueda saltárselas: un filtro por región antes del inicio de sesión, un kit de inicio después del inicio de sesión que creó al jugador.
• La moderación tiene que actuar de inmediato: revocar sesiones, suspender, banear un dispositivo, con un evento banned que escuchan todos los sistemas en ejecución.
• El contexto declarado (región, plataforma, build) tiene que llegar a todos los hooks posteriores sin que cada uno vuelva a leer al jugador para averiguarlo.
• No hay una alternativa más liviana. Todos los demás módulos identifican a quien los llama a través de este, y auth no se puede desactivar mientras alguno de ellos necesite un actor jugador: el configurador de módulos se niega y enumera los módulos que dependen de él.

Quién hace qué

En resumen

// client — one call per provider; create-on-first-sign-in is a flag
var session = await PlayServ.Auth.SignIn(Provider.Device, create: true);
await PlayServ.Auth.Link(Provider.Steam);          // one player, many identities

// client — one call per provider; create-on-first-sign-in is a flag
const session = await PlayServ.auth.signIn(Provider.Device, { create: true });
await PlayServ.auth.link(Provider.Steam);    // one player, many identities

# client — one call per provider; create-on-first-sign-in is a flag
session = await playserv.auth.sign_in(Provider.DEVICE, create=True)
await playserv.auth.link(Provider.STEAM)     # one player, many identities

// client — one call per provider; create-on-first-sign-in is a flag
Client->Auth->SignInWithProvider(FPSProviderId::Device, Credential,
    TPSOnResult<FPSSession>::CreateWeakLambda(this, [this](const TPSResult<FPSSession>& Result)
    {
        if (!Result.HasValue()) { return; }
        // one player, many identities — add Steam to the same account
        Client->Auth->Providers->Link(FPSProviderId::Steam, SteamCredential);
    }));
// co_await support ships later: a built-in SDK coroutine wrapper that respects Unreal's GC and threading.

// client — one call per provider; create-on-first-sign-in is a flag
var session = await PlayServ.Auth.SignIn(Provider.Device, create: true);
await PlayServ.Auth.Link(Provider.Steam);          // one player, many identities

Cada punto se personaliza en el mismo lugar donde se declara. Todas las formas que puede tomar un handler están reunidas en Extensibility:

[Before(Auth.SignIn)]                          // a gate: it may refuse, and it is fail-closed
public static Verdict GateRegion(SignInAttempt a) =>
    a.Region == "sanctioned"
        ? Hook.Reject(Problem.Forbidden, "region not served")
        : Hook.Continue(a);

[After(Auth.SignIn, created: true)]            // an observer: it watches, it cannot refuse
public static async Task GrantStarterPack(Player player)
{
    await player.Inventory.Grant("chest.gold", count: 1);
}

// a gate: it may refuse, and it is fail-closed
export const gateRegion = before(Auth.signIn, (a: SignInAttempt) =>
  a.region === 'sanctioned'
    ? Hook.reject(Problem.forbidden, 'region not served')
    : Hook.continue(a));

// an observer: it watches, it cannot refuse
export const grantStarterPack = after(Auth.signIn, { created: true },
  async (player: Player) => {
    await player.inventory.grant('chest.gold', { count: 1 });
  });

@before(auth.sign_in)                          # a gate: it may refuse, and it is fail-closed
def gate_region(a: SignInAttempt) -> Verdict:
    if a.region == "sanctioned":
        return Hook.reject(Problem.FORBIDDEN, "region not served")
    return Hook.continue_(a)

@after(auth.sign_in, created=True)             # an observer: it watches, it cannot refuse
async def grant_starter_pack(player: Player):
    await player.inventory.grant("chest.gold", count=1)

El panel dibuja justamente la forma declarada: en cada punto ves sus handlers, su tipo y el orden final en que se ejecutan. El tipo decide qué pasa cuando falla un handler:

El modelo

Un jugador es portador de identidades, no una fila de tu esquema, y su identificador es estable y nunca se reutiliza, ni siquiera en una fusión: el id de un jugador fusionado se sigue resolviendo en lugar de convertirse en una referencia colgante. Un vínculo es una terna: proveedor · sujeto externo · jugador.

Las tres máquinas de estados.

Lo que declaras tú.

Dónde se configura un proveedor. En el plano de operador, no en el código: la credencial de una tienda digital no tiene por qué estar en un repositorio. Lo declarado llega a la consola de administración solo para lectura.

Qué implica otorgar un rol. Los roles no son solo asunto del operador: la interfaz incluye otorgar y revocar para un jugador, así que un juego puede ascender a un oficial de gremio o darle sus poderes al organizador de un torneo desde su propio código.

De qué están hechos los roles y qué desbloquean se explica en Access & Roles.

Errores

• Sin credencial, o con una vencida, la respuesta es not authenticated y una renovación lo resuelve. Una credencial revocada recibe la misma respuesta, pero renovarla no sirve: solo un nuevo inicio de sesión.
• Volver a presentar una credencial ya rotada es un conflicto: gracias a eso la rotación se puede detectar en lugar de tolerarse en silencio.
• Un jugador baneado o suspendido, al igual que una huella baneada, recibe forbidden, y no tiene sentido repetir.
• Que el par proveedor+sujeto ya esté en uso es un conflicto, y se puede repetir después de elegir una fusión; una segunda cuenta del mismo proveedor es un conflicto que ningún reintento va a cambiar.
• Desvincular el último método de inicio de sesión es un rechazo de validación: dejaría una cuenta a la que nadie puede entrar.
• Fusionar un jugador que ya fue fusionado es un conflicto: merged es terminal.
• Si el proveedor no está disponible, la respuesta es unavailable y vale la pena reintentar con backoff; si el proveedor rechaza la credencial, la respuesta es not authenticated y vale un reintento, no un bucle.
• Si se supera la frecuencia de intentos de inicio de sesión, la respuesta cae en la categoría de límite de frecuencia e indica un plazo.

Límites

Los números llegarán con el capítulo sobre los límites de la plataforma; lo que pasa al alcanzar cada tope ya está definido.

• Sesiones simultáneas por jugador: según la política declarada, se expulsa la más antigua con un evento o se rechaza la nueva. No hay valor predeterminado.
• Intentos de inicio de sesión por período e intentos de vincular un par en uso: un límite de frecuencia con plazo, y el contador de intentos queda en el historial.
• Vínculos por jugador: vincular otro proveedor se rechaza como conflicto.
• Vida útil de una credencial: not authenticated, y se puede repetir tras una renovación. Vida útil de una credencial de renovación: solo un nuevo inicio de sesión.
• Retención de un jugador anónimo que no inicia sesión: se elimina según la política declarada, con un evento. La política se declara de forma explícita; no hay valor predeterminado.
• Entradas en la lista de huellas baneadas: se rechaza la nueva entrada, y las antiguas nunca se expulsan en silencio.