Unwrapped SteamProfile

[nielslanting]

The steam_id of users authenticated through Steam was always set to 0.
The response of the AuthenticateUserTicket looks like this:

{
    "response": {
        "params": {
            "result": "OK",
            "steamid": "76561197993712720",
            "ownersteamid": "76561197993712720",
            "vacbanned": false,
            "publisherbanned": false
        }
    }
}

Now it properly sets the correct steam_id in the database.

[nielslanting]

Also worth mentioning, the steamid is returned as a string. It get's converted to a uint64. Everywhere it is used it gets converted back to a string. The database type is text. Why is the steamid getting converted to a uint64?

[zyro]

Per Steam docs steamid is a uint64 and serialised over JSON as a string. We don't need the underlying numeric value at all it's just checked for input validation purposes. Do you think it's more reliable to just use the string as it's received?

I can also see we use the v0001 which was latest when that integration was written but per the docs it looks like v1 is now latest. @nielslanting What do you think about updating and retesting if you have a test case set up already?

[nielslanting]

I am not sure whether it's more reliable or not so I will leave the steamid as is.

The response of the v1 endpoint is identical to the v0001 endpoint.

[zyro]

@nielslanting Thanks!

[nielslanting]

I retested it with the v1 endpoint and it works. But this begs the question is no one using the Steam integration?

[nielslanting]

If the users enters an invalid ticket an account with steamid 0 is created. I don't think that's expected behavior. The response of a request with an invalid ticket to the AuthenticateUserTicket endpoint looks like this: 200 OK

{
    "response": {
        "error": {
            "errorcode": 3,
            "errordesc": "Invalid parameter"
        }
    }
}

[zyro]

It's not the most popular integration. Most PC games I'm aware of that use Nakama have preferred email/password authentication for various reasons - usually to ensure Steam and non-Steam audience accounts are unified, but it's up to them.

Looks like in error cases the Steam Web API does not set a non-200 response code, and the decoding of the result does not fail so the Go default value for a uint64 of 0 is used. We can add a guard to ensure that doesn't happen and optionally attempt to decode the "error" field.