I’ve configured my 3.16.0 server with the credentials_json for the updated Google auth process for Google Play Games 0.11.x and also updated my Unity project to match.
Now when a user authenticates with AuthenticateGoogleAsync, passing the new server side token, it creates a new user account with a different (incorrect) Google ID to their existing account. The Google ID returned from GooglePlayGames.Authenticate is their correct ID but the ID that Nakama derives from the token is different and is formatted with a letter prefix.
For example, my Google ID is 111178834567830394331 and the new account has the ID g09515347187652732951.
Is this a bug, or am I doing something wrong? I know this is a new feature and the documentation is still a bit patchy. Thanks.
Probably not a Nakama issue then. I’m suspecting something to do with Google’s “Next Generation Player ID” which is an app scoped player ID similar to that used by Facebook. However, existing players are supposed to retain their previous ID for the game. Besides, I haven’t enabled next gen IDs for my game yet. All very strange,
The call in Nakama to retrieve the player data is returning data for the game Puzzle Master, which is not my game! I’ve checked the config in config.yml and my setup in Unity and Google Play and can find no errors.
I have checked the GooglePlayGames instance and it is definitely my game that I am authenticating with in the client, and the ID token from RequestServerSideAccess is being passed into Nakama.AuthenticateGoogleAsync. Something is seemingly going wrong on the server side.
Thanks for getting back. I’ve checked the config to make sure the credentials belong to my game, I’ve created new credentials on the app and tried those with the same result. I’ve also used a Google Admin account to look up my Client ID and it returns the name of my app correctly.
I think I have an answer, and I think it requires a small change to Nakama for all games that currently use legacy player IDs.
The documentation on this is very scant, but it seems that Google is moving everyone to “Next Generation Player IDs” even if they are an existing user. These IDs are application specific so you will get a different ID for each game you play.
In order for game servers to manage this change in IDs, they are providing the old ID along with the new ID so you can remap the IDs in the database. For example, the call to players/me above returns:
Amazing work figuring this out, @DaveOak. Thank you.
Now, I wonder if it is safe to assume that we should always return the originalPlayerId if present. I don’t truly understand the implications of this part This is only populated for calls ...and only to clients that support remapping player IDs. Would the server need to be aware of this id mapping support in the client?
I assume that, eventually, studios need to migrate the Ids, wouldn’t it be better to it as soon as possible rather than later? I imagine that it’s an unavoidable transition.
Rereading your post, I think the remapping takes place purely in the server and the client need never be aware of the Google ID(s).
The client gets and passes on a short lived IdToken from Google login, which the server translates to the ID(s) using Google APIs in order to find the player record. It need never be returned to the client which only really needs the Nakama player ID.
I think the approach is for the server to get the player record from Google and if it contains an originalPlayerId, look for a matching record in the database and if found change the ID to the (new) playerId.
originalPlayerId : The player ID that was used for this player the first time they signed into the game in question. This is only populated for calls to player.get for the requesting player, only if the player ID has subsequently changed, and only to clients that support remapping player IDs.
In this context, I think a game server is a client of the Google APIs.
How the API knows whether or not you support remapping is a mystery! In my tests this field was returned so long as it had previously been used (i.e. pre-existing game accounts).