We are trying to generate an access token for one of our clients using their username and password through the https://unityapi.webrootcloudav.com/auth/token endpoint. However, if the password contains an & symbol, we always receive the error message "Username or password is invalid”.
When testing with other accounts and passwords (not containing an & character), things work fine. We double checked and we are sending the password field (as any other field) properly URL encoded. My only guess is that the receiving API server is not decoding these values correctly.
Would you be able to confirm this a problem on your end or is there something we need to check again?
Thanks for any help.
Best answer by aqilaView original
Hi Steven R,
Thanks for raising this issue. It does seem strange that the GSM would allow a password that UnityAPI considers invalid.
I’ll look into it for you and respond with an answer as soon as I can.
Hello Steven R,
We have taken a look at your problem. It is not an ampersand character issue but rather an encoding issue at the client end.
If you ensure that the parameters are encoded with application/x-www-form-urlencoded it will work.
(Do not select raw as body encoding via Postman- else it produces the errors that you see)
Hope this helps.
Hi Ail and Shandley,
Thanks a lot for your quick response and for investigating the issue. We are effectively sending the request using these headers and making sure we’re encoding it properly.
Here is a (fictional) example of the cURL request as generated by Postman:
Sending this to a requestbin.com, we can verify that the request’s body arrives encoded:
The password that is causing us trouble contains all of these characters: + & * >. Would you able to give it another try with all of these and see if that gives you an error please?
In any case, we asked our customer to change their password, I’m sure we’ll get it to work that way.
Thanks again for your help.
Thanks for the feedback. We will test further with all the characters you list included. In the meanwhile, yes the logical solution would be a password change.
Hello Steven R,
We tested the list of special characters and get no issues.
Can you DM me so we can drill down deeper on your specific case and examine the relevant logs via username and time windows.
Thanks for digging deeper into this. Our customer changed their password to make it work. All the credentials we use at the moment are working fine!
We have the same problem again, this time with an email address for username that contains the + character. It fails both with and without encoding. I will send you a DM to look closer into this.
Yes please do DM me so we can investigate further.