Pular para o conteúdo principal

Segredos compartilhados do jogador

Os segredos compartilhados do jogador são um novo tipo de chave pseudossecreta, compartilhada entre os clientes do jogo. Usando uma API, ela pode ser trocada pela chave RSA pública do título e pode ser usada para realizar o registro de contas. Os títulos podem ter várias chaves compartilhadas do jogador e podem configurá-las e revogá-las à vontade, por meio das chamadas da API Admin Create, Update, Delete, List. Os segredos compartilhados do jogador devem ser incorporados aos respectivos clientes, pois não há APIs de cliente para recuperá-los, sejam autenticadas ou não.

Chave pública do título

O segredo compartilhado do jogador é então enviado para GetTitlePublicKey. Se a chave for válida, a API retornará uma matriz de bytes de blob RSA CSP codificada em Base 64 que pode criptografar 237 bytes de dados. Todas as APIs que permitem a criação de contas agora aceitam o envio de uma solicitação de registro como um payload criptografado no campo EncryptedRequest.
Os campos padrão TitleId, InfoRequestParameters e CreateAccount não devem ser incluídos no payload criptografado.

Usando a chave pública do título para registrar

Veja a seguir um código de exemplo para registrar um jogador usando LoginWithCustomID e a chave pública do título.

Segredo do jogador

Parte do novo sistema de registro é um novo campo chamado PlayerSecret. Se definido, ele permite assinar cabeçalhos de solicitação que são validados pelo servidor durante chamadas de API para todos os serviços, incluindo solicitações de login. O segredo do jogador só pode ser definido uma vez por usuário por título. Um usuário com vários títulos no mesmo estúdio precisa definir o segredo do jogador para cada um deles. Se o segredo do jogador ainda não tiver sido definido durante o registro, é possível defini-lo chamando SetPlayerSecret. Há APIs de administrador e de servidor que permitem definir o segredo do jogador com um novo valor, mesmo que ele já tenha sido definido anteriormente.
Depois de definido, o segredo do jogador deve ser armazenado com segurança no dispositivo, pois ele não pode ser recuperado se for perdido e não existem APIs para recuperá-lo.

Usando o segredo do jogador para assinar solicitações de API

O exemplo de código a seguir constrói um cabeçalho de assinatura que pode ser usado para assinar solicitações de API. O formato do cabeçalho de assinatura é mostrado abaixo. jsonRequestModel.utcTimeStampInISO.playerSecret

Usando a imposição de políticas

As Políticas de API agora podem ser usadas para impor estes cenários.
  • Uma solicitação do cliente é um payload criptografado.
  • Uma solicitação do cliente contém cabeçalhos assinados.
Mesmo sem usar a imposição de políticas, se um payload criptografado for enviado (ou se os cabeçalhos forem enviados), eles serão validados. Se não estiverem formados corretamente, ocorrerá um erro. Para criar uma política que exija cabeçalhos em uma API específica, use uma instrução Deny. Isso cria uma política que exige cabeçalhos em todas as chamadas que você pode fazer e que não são permitidas pela instrução Allow. As instruções de política têm uma propriedade chamada ApiConditions. ApiConditions contém uma propriedade chamada HasSignatureOrEncryption, que é uma enumeração com três valores possíveis:
  • Any
  • True
  • False
O padrão (se não for definido pela política) é Any.
A política de exemplo a seguir permite todas as chamadas de API (exceto chamadas não criptografadas ou sem cabeçalhos) para LoginWithCustomID.
A instrução Deny acima contém HasSignatureOrEncryption: False. Isso significa que todas as solicitações que não têm assinatura ou criptografia são rejeitadas. Em outras palavras, todas as solicitações que têm cabeçalhos de assinatura ou criptografia são permitidas com base na Allow the rest policy.
Última modificação em 6 de outubro de 2026