Secrets partagés de joueur
Les secrets partagés de joueur constituent un nouveau type de pseudo-clé secrète, partagée entre les clients de jeu. À l’aide d’une API, elle peut être échangée contre la clé RSA publique du titre et peut être utilisée pour effectuer l’inscription de comptes. Les titres peuvent avoir plusieurs clés partagées de joueur, et peuvent les configurer et les révoquer à volonté, via les appels d’API Admin Create, Update, Delete, List. Les secrets partagés de joueur doivent être intégrés dans les clients respectifs, car il n’existe aucune API client permettant de les récupérer, qu’elle soit authentifiée ou non.Clé publique du titre
Le secret partagé de joueur est ensuite envoyé à GetTitlePublicKey. Si la clé est valide, l’API renvoie un tableau d’octets de blob CSP RSA encodé en Base 64, capable de chiffrer 237 octets de données. Toutes les API qui permettent de créer des comptes acceptent désormais la publication d’une demande d’inscription sous forme de charge utile chiffrée dans le champEncryptedRequest.
Les champs standard
TitleId, InfoRequestParameters et CreateAccount ne doivent pas être inclus dans la charge utile chiffrée.Utilisation de la clé publique du titre pour l’inscription
Voici un exemple de code permettant d’inscrire un joueur à l’aide deLoginWithCustomID et de la clé publique du titre.
Secret du joueur
Le nouveau système d’inscription comprend un nouveau champ appeléPlayerSecret. S’il est défini, il vous permet de signer les en-têtes de requête, qui sont validés par le serveur lors des appels d’API à tous les services, y compris les demandes de connexion.
Le secret du joueur ne peut être défini qu’une seule fois par utilisateur et par titre. Un utilisateur possédant plusieurs titres dans le même studio doit définir le secret du joueur pour chacun d’eux.
Si le secret du joueur n’a pas déjà été défini lors de l’inscription, il est possible de le définir en appelant SetPlayerSecret. Il existe des API admin et serveur qui permettent de définir le secret du joueur sur une nouvelle valeur, même s’il a déjà été défini.
Une fois défini, le secret du joueur doit être stocké de manière sécurisée sur l’appareil, car il n’est pas récupérable en cas de perte, et il n’existe aucune API permettant de le récupérer.
Utilisation du secret du joueur pour signer les requêtes d’API
L’exemple de code suivant construit un en-tête de signature pouvant être utilisé pour signer les requêtes d’API. Le format de l’en-tête de signature est présenté ci-dessous.jsonRequestModel.utcTimeStampInISO.playerSecret
Utilisation de l’application d’une stratégie
Les stratégies d’API peuvent désormais être utilisées pour imposer ces scénarios.- Une requête client est une charge utile chiffrée.
- Une requête client contient des en-têtes signés.
Deny. Cela crée une stratégie exigeant des en-têtes sur tous les appels que vous pouvez effectuer et qui ne sont pas autorisés par l’instruction Allow.
Les instructions de stratégie possèdent une propriété appelée ApiConditions. ApiConditions contient une propriété appelée HasSignatureOrEncryption, qui est une énumération avec trois valeurs possibles :
AnyTrueFalse
La valeur par défaut (si elle n’est pas définie par la stratégie) est
Any.LoginWithCustomID.
Deny ci-dessus contient HasSignatureOrEncryption: False. Cela signifie que toutes les requêtes dépourvues de signature ou de chiffrement sont rejetées. En d’autres termes, toutes les requêtes qui possèdent des en-têtes de signature ou un chiffrement sont autorisées en vertu de Allow the rest policy.