Solved

API not decoding password properly

  • 23 June 2022
  • 8 replies
  • 113 views

Hi,

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 regards,
Steven

icon

Best answer by aqila 28 June 2022, 14:56

View original

8 replies

Userlevel 2

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. 

 

 

Userlevel 2

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.

Thanks,

Aqil

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:

curl --location --request POST 'https://unityapi.webrootcloudav.com/auth/token' \
--header 'Accept: application/json' \
--header 'Authorization: Basic <example token>' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'username=user@example.com' \
--data-urlencode 'password=abc123+&*>' \
--data-urlencode 'grant_type=password' \
--data-urlencode 'scope=*'


Sending this to a requestbin.com, we can verify that the request’s body arrives encoded:

username=user%40example.com&password=abc123%2B%26%2A%3E&grant_type=password&scope=%2A


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.

Best regards,
Steven

Userlevel 2

Hello Steven,

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.

Thanks,

Aqil

Userlevel 2

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,

Aqil

Hi Aqil,

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!

Best regards,

Steven

Hi Aqil,

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.

Best regards,
Steven

Userlevel 2

Hi Steven,

Yes please do DM me so we can investigate further.

Thanks,

Aqil

Reply