Cette page n’est pas encore traduite : la version anglaise est affichée.

Auth & Players

La connexion est une étape que vous pouvez surcharger, pas une boîte noire. Fournisseurs, sessions, liaison d’identités, bannissements. Chaque point du parcours — avant et après la connexion, avant et après une liaison, avant et après une fusion, à chaque changement de statut — est un point d’extension déclaré, d’un type déclaré : une barrière, qui peut refuser l’étape, ou un observateur, qui ne le peut pas.

Quand l’utiliser

• Les joueurs doivent se connecter (appareil, e-mail, Apple, Google, Steam ou méthode personnalisée), et la création du compte à la première connexion (sign-in) est une simple option, pas un second parcours.
• Un compte invité doit pouvoir évoluer plus tard : Link ajoute Steam sans perdre la progression, et une fusion (merge) réunit deux comptes en un seul joueur.
• Une règle doit s’exécuter là où personne ne peut la contourner : une barrière (gate) par région avant la connexion, un pack de départ après la connexion qui a créé le joueur.
• La modération doit agir immédiatement : révoquer les sessions, suspendre, bannir un appareil, avec un événement banned que reçoivent tous les systèmes actifs.
• Le contexte déclaré (région, plateforme, build) doit parvenir à chaque hook suivant, sans que chacun doive relire le joueur pour l’obtenir.
• Il n’existe rien de plus léger pour le remplacer. Tous les autres modules identifient leur appelant grâce à celui-ci, et auth ne peut pas être désactivé tant que l’un d’eux a besoin d’un acteur joueur : le configurateur de modules refuse et nomme les modules qui en dépendent.

Qui fait quoi

En bref

// 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

Chaque point se personnalise là où il est déclaré ; les formes que peut prendre un handler sont réunies dans 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)

La forme déclarée est exactement ce qu’affiche le panneau : chaque point montre ses handlers, leur type et l’ordre résolu. Le type détermine ce qui se passe quand un handler échoue :

Le modèle

Un joueur porte une identité ; ce n’est pas une ligne de votre schéma, et son identifiant est stable et jamais réutilisé — y compris lors d’une fusion : l’id d’un joueur fusionné continue de se résoudre au lieu de devenir une référence pendante. Une liaison (link) est un triplet : fournisseur · sujet externe · joueur.

Les trois machines à états.

Ce que vous déclarez.

Où se configure un fournisseur. Dans le plan opérateur, pas dans le code : les identifiants d’un store n’ont rien à faire dans un dépôt. Ce qui est déclaré arrive dans la console d’administration en lecture seule.

Ce qu’apporte l’attribution d’un rôle. Les rôles ne sont pas l’affaire du seul opérateur : l’interface propose l’attribution et le retrait d’un rôle pour un joueur, si bien qu’un jeu peut, depuis son propre code, promouvoir un officier de guilde ou confier ses pouvoirs à l’organisateur d’un tournoi.

La composition des rôles et ce qu’ils débloquent sont décrits dans Access & Roles.

Erreurs

• Sans identifiant, ou avec un identifiant expiré, la réponse est not authenticated, et un renouvellement règle le problème. Un identifiant révoqué reçoit la même réponse, mais là, le renouvellement n’y peut rien : seule une nouvelle connexion fonctionne.
• Un identifiant déjà renouvelé et présenté une seconde fois est un conflit : c’est ce qui rend la rotation détectable au lieu de la tolérer en silence.
• Un joueur banni ou suspendu, ainsi qu’une empreinte bannie, reçoivent forbidden, et il est inutile de réessayer.
• Une paire fournisseur+sujet déjà prise est un conflit, qu’on peut réessayer après avoir choisi une fusion ; un second compte du même fournisseur est un conflit qu’aucune nouvelle tentative ne changera.
• Délier la dernière méthode de connexion est un refus de validation : plus personne ne pourrait accéder au compte.
• Fusionner un joueur déjà fusionné est un conflit : merged est terminal.
• Un fournisseur indisponible répond unavailable, et il vaut la peine de réessayer avec un délai croissant (backoff) ; un fournisseur qui rejette l’identifiant répond not authenticated, ce qui justifie une seule nouvelle tentative, pas une boucle.
• Un dépassement du nombre de tentatives de connexion reçoit une réponse de la catégorie limitation de débit (rate limit), avec un délai.

Limites

Les valeurs chiffrées arriveront avec le chapitre sur les limites de la plateforme ; ce qui se passe à chaque plafond est déjà fixé.

• Sessions simultanées par joueur : selon la politique déclarée, éviction de la plus ancienne avec un événement, ou refus de la nouvelle. Il n’y a pas de valeur par défaut.
• Tentatives de connexion par période, et tentatives de liaison d’une paire déjà prise : une limitation de débit avec un délai, et le compteur de tentatives reste dans l’historique.
• Liaisons par joueur : la liaison d’un fournisseur supplémentaire est refusée comme un conflit.
• Durée de vie d’un identifiant : not authenticated, qu’un renouvellement résout. Durée de vie d’un identifiant de renouvellement : seule une nouvelle connexion.
• Rétention d’un joueur anonyme sans aucune connexion : suppression selon la politique déclarée, avec un événement. La politique se déclare explicitement ; il n’y a pas de valeur par défaut.
• Entrées de la liste des empreintes bannies : un ajout est refusé, et les anciennes entrées ne sont jamais évincées en silence.