First, I would agree with Hamza, that all the error codes should be checked. It is the case that you will not get back all the error codes for all the things wrong with a call, if multiple things are wrong with the call in question - it will early-out on the first error encountered and return the specific response info for that problem.
We do have a bug open to review the error codes returned, to ensure that the information returned is accurate. Because this hasn't been called out as an issue by most developers (Hamza was, as he said, the first reporter for this), it has not been prioritized as yet. We're using our Bugs forum as a way for developers to help let us know which items are most impacting (via votes), so I'm moving this post there, so that it can be found more readily.
However, in my own testing, I do see two differences from your tests when calling RegisterPlayFabUser:
{"code":400,"status":"BadRequest","error":"UsernameNotAvailable","errorCode":1009,"errorMessage":"UsernameNotAvailable","errorDetails":{"Username":["User name already exists."]}}
{"code":400,"status":"BadRequest","error":"EmailAddressNotAvailable","errorCode":1006,"errorMessage":"EmailAddressNotAvailable","errorDetails":{"Email":["Email address already exists. "]}}
If you're not seeing this, can you provide the specifics - Title ID, PlayFab ID of the existing user(s), specifics of the call being made?
Hey Alberto, you definitely should make validation at "code level". That's what I'm doing and it's what the login samples on github exposes also. I know it's a lot of work to check each input field for the different login or register screens.
And at the same time, PlayFab should seriously consider fixing those error codes. I remember reporting similar issue months ago.
Thanks for the responses, Brendan and Hamza.
Brendan, you're right, the error codes for this two cases are indeed 1009 and 1006. When I checked the tests I realized that the password we were using for them was too short, hence the wrong error code. As you said, I was getting the first error encountered. Once I tried a proper password I got the correct error code.
For the field validation we'll implement the necessary measures to check the strings before making the call, avoiding further unnecesary complications.
Thanks again for your help,
Alberto.
This still doesn't work correctly:
It would also be great if you could add a CloudScript hook for validating display names. For example, we want to allow only alphanumeric characters, plus underscores and dashes.
,This still doesn't work:
The return values are correct, but the docs need an update - I'll work with the tools team on that. Errors for your scenarios are:
Bad username or email address (doesn't exist in the title) - 1001 - AccountNotFound
Bad email address (malformed) - 1000 - InvalidParams
Bad username or password (too short/long) - 1000 - InvalidParams
Bad password (incorrect) - 1003 - InvalidUsernameOrPassword
Username already taken - 1009 - UsernameNotAvailable
Title Display Name already taken - 1058 - NameNotAvailable
If you have any scenarios not covered here, can you specify what the API call is that you're making, and what your repro steps are?
Hi,
I think there's a small confusion here. RegisterPlayFabUser can't return AccountNotFound or InvalidUsernameOrPassword, right? LoginWithEmailAddress can throw those error codes, but why would register complain about failed logins?
Anyway, I'm fine with getting InvalidParams for malformed email or password, as long as I can tell what happened. I see that errorDetails contains keys such as "Email" which I can use, but those are strings, so I'm a bit uncomfortable with them. Are they part of the API contract, and covered by regression tests? Can you put those keys in the docs as well? It wouldn't be very nice if someone changes "Email" to "email", and my game no longer understands what went wrong, and cannot communicate the error to the user (by highlighting the offending field in the register form).
Correct, sorry for the confusion. RegisterPlayFabUser is specifically used to created an account, not to sign into one. So neither of those errors would make sense for it. I simply traced the logic for auth in general, to make sure I could provide the full set of all possible returns, but you are correct that those two are in code paths that RegisterPlayFabUser wouldn't follow.
We do thorough testing on all API calls. I'll add a work item for the tools team to add documentation for the errorDetails in addition.
1 Person is following this question.