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 campoEncryptedRequest.
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 usandoLoginWithCustomID e a chave pública do título.
Segredo do jogador
Parte do novo sistema de registro é um novo campo chamadoPlayerSecret. 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.
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:
AnyTrueFalse
O padrão (se não for definido pela política) é
Any.LoginWithCustomID.
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.