Identité des joueurs

Comment Inngame sait qui écrit, et comment l'historique d'un joueur le suit de son téléphone à son PC.

Anonyme par défaut

Au premier démarrage du SDK sur un appareil, il ouvre une session et reçoit un jeton d'appareil privé. Cet appareil est un joueur anonyme : il peut écrire tout de suite, sans connexion. Le jeton est gardé en local : PlayerPrefs dans Unity (ou votre ITokenStore), le trousseau sur iOS, le localStorage sur le web.

Identité non vérifiée

Passez l'identifiant de votre propre compte. L'équipe le voit avec un nom et un e-mail, et il reste attaché au joueur de cet appareil.

await Inngame.Identify("player-1842", "Camille", "camille@example.com");

Inngame.identify(userId: "player-1842", name: "Camille", email: "camille@example.com")

await Inngame.identify({ userId: "player-1842", name: "Camille", email: "camille@example.com" });

Un identifiant non vérifié est une étiquette, pas une preuve : n'importe qui peut envoyer n'importe quel identifiant depuis un build modifié. Inngame ne s'en sert donc jamais pour réunir des appareils. Deux appareils qui envoient le même identifiant non vérifié restent deux joueurs distincts, et aucun ne voit les messages de l'autre. Si l'identifiant appartient à un joueur vérifié, l'appel est refusé (identity_requires_token). Pour que l'historique suive un joueur d'un appareil à l'autre, utilisez un JWT ou Steam.

Certains champs sont posés par le serveur seul et ignorés dans les métadonnées du joueur : subscription_status, subscriptionStatus, subscription_product, subscription_expires_at, plan, renews_on, paid, is_paying, purchase_token, appAccountToken, obfuscatedAccountId, revenuecat_id et adapty_profile_id. Ils viennent des webhooks de vos boutiques : un joueur ne peut pas se déclarer abonné. Il en va de même pour les événements d'abonnement et les noms d'événements qui commencent par inngame., que le SDK ne peut pas envoyer.

Pour les achats, chaque joueur reçoit un jeton d'achat (un UUID émis par Inngame : Inngame.PurchaseToken dans Unity, Inngame.purchaseToken sur iOS, Inngame.user.purchaseToken sur le web). Quand un appareil anonyme rejoint un joueur vérifié, les achats faits avec son ancien jeton restent rattachés à ce joueur. Passez-le à la boutique ou à votre service d'abonnement ; Inngame rapproche les événements d'abonnement par ce jeton, ou par l'identifiant de compte d'un joueur vérifié. Voir Intégrations.

Identité vérifiée par JWT

Votre serveur de jeu signe un JWT de courte durée avec le secret d'identité de l'app (inbox → Réglages → Apps → votre app). Le SDK le transmet à Inngame, qui vérifie la signature.

• Algorithme : HS256 uniquement.
• Champs obligatoires : user_id (texte ou nombre) et exp (secondes Unix).
• Champs facultatifs : name, email, nbf.
• Ne mettez jamais le secret d'identité dans le build du jeu. Signez sur votre serveur.

// Node.js, on your game server (npm i jsonwebtoken)
import jwt from "jsonwebtoken";

app.get("/inngame-token", requireLogin, (req, res) => {
  const token = jwt.sign(
    { user_id: req.user.id, name: req.user.displayName, email: req.user.email },
    process.env.INNGAME_IDENTITY_SECRET,
    { algorithm: "HS256", expiresIn: "10m" }
  );
  res.json({ token });
});

# Python, on your game server (pip install pyjwt)
import time, jwt

def inngame_token(user):
    return jwt.encode(
        {"user_id": user.id, "name": user.display_name, "exp": int(time.time()) + 600},
        INNGAME_IDENTITY_SECRET,
        algorithm="HS256",
    )

// In the game
string jwt = await MyBackend.Get("/inngame-token");
bool ok = await Inngame.IdentifyWithToken(jwt);

let jwt = try await api.inngameToken()
Inngame.identify(userId: user.id, token: jwt)   // the token's user_id wins over userId

const { token } = await fetch("/inngame-token").then((r) => r.json());
await Inngame.identify({ token });

Une signature fausse, un user_id absent ou un jeton expiré est refusé avec identity_rejected. Renouveler le secret d'identité (réglages de l'app, ou POST /v1/apps/:id/rotate-identity-secret) invalide les jetons en circulation ; passez unverify: true pour marquer aussi les joueurs existants comme non vérifiés (les joueurs vérifiés par Steam le restent).

Identité vérifiée par Steam

Sur les builds Steam, le joueur est déjà connecté à Steam. Le SDK demande à Steam un ticket Web API pour l'identité "inngame" et l'envoie ; le serveur Inngame le vérifie auprès de Steam (ISteamUserAuth/AuthenticateUserTicket) avec votre clé Web API d'éditeur, et obtient le SteamID du joueur.

1. Branchez Steam dans le tableau de bord (Réglages → Apps → votre app → Intégrations → Steam) : l'App ID Steam et une clé Web API d'éditeur. Voir Intégrations.
2. Dans le jeu, appelez Inngame.IdentifySteam(getTicketHex). Le démarrage Unity donne des fonctions toutes prêtes pour Steamworks.NET et Facepunch.Steamworks.

Le ticket ne prouve que le SteamID : un identifiant d'utilisateur envoyé avec lui sans JWT est ignoré. L'identité Steam est intégrée au SDK Unity ; les SDK iOS et web n'ont pas d'appel Steam.

Erreurs : steam_not_configured (étape 1 manquante) ou steam_ticket_rejected.

Ce que devient l'historique

• Un appareil anonyme s'identifie, vérifié, comme un joueur connu : l'appareil rejoint ce joueur et apporte sa conversation anonyme. L'équipe voit un seul fil.
• Un appareil anonyme s'identifie comme un nouveau joueur : le joueur anonyme devient simplement ce joueur.
• Identifiant non vérifié déjà utilisé sur un autre appareil : pas de fusion. Chaque appareil garde son joueur et son historique.
• Un appareil identifié passe à un autre compte : il devient l'autre joueur, sans emporter l'historique du premier.
• Même joueur vérifié sur un second appareil : les deux appareils affichent le même historique et reçoivent tous deux les notifications push.

Déconnexion et suppression

Inngame.Logout() (iOS Inngame.logout(), web Inngame.logout()) détache l'appareil : il continue avec un nouveau joueur anonyme et ne reçoit plus les notifications push de ce joueur. Inngame.DeleteData() (iOS Inngame.shared.deleteMyData(), web Inngame.deleteData()) supprime le joueur, ses conversations et ses photos sur le serveur, puis les données locales. Depuis l'API, un admin peut faire de même avec DELETE /v1/users/:id.