Skip to main content
Customer Support Customer Support
Solved

API not decoding password properly

S
Fresh Face

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

Best answer by aqila

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

View original
    Did this help you find an answer to your question?

    8 replies

    S
    • shandleyOpenText Employee
    • OpenText Employee
    • 7 replies
    • June 23, 2022

    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. 

     

     

    ProTruckDriver
    TylerM
    Ssherjj
    3 people like this
    • ProTruckDriver
      ProTruckDriver
    • TylerM
      TylerM
    • Ssherjj
      Ssherjj
    aqila
    Community Manager
    Forum|alt.badge.img+1
    • aqila
    • Community Manager
    • 29 replies
    • June 24, 2022

    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

    Product Manager, Opentext
    ProTruckDriver
    Ssherjj
    2 people like this
    • ProTruckDriver
      ProTruckDriver
    • Ssherjj
      Ssherjj
    S
    Fresh Face
    • Steven R
    • Author
    • Fresh Face
    • 3 replies
    • June 24, 2022

    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

    ProTruckDriver
    Ssherjj
    2 people like this
    • ProTruckDriver
      ProTruckDriver
    • Ssherjj
      Ssherjj
    aqila
    Community Manager
    Forum|alt.badge.img+1
    • aqila
    • Community Manager
    • 29 replies
    • June 24, 2022

    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

    Product Manager, Opentext
    ProTruckDriver
    Ssherjj
    2 people like this
    • ProTruckDriver
      ProTruckDriver
    • Ssherjj
      Ssherjj
    aqila
    Community Manager
    Forum|alt.badge.img+1
    • aqila
    • Community Manager
    • 29 replies
    • Answer
    • June 28, 2022

    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

    Product Manager, Opentext
    ProTruckDriver
    Ssherjj
    TripleHelix
    3 people like this
    • ProTruckDriver
      ProTruckDriver
    • Ssherjj
      Ssherjj
    • TripleHelix
      TripleHelix
    S
    Fresh Face
    • Steven R
    • Author
    • Fresh Face
    • 3 replies
    • July 7, 2022

    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

    ProTruckDriver
    1 person likes this
    • ProTruckDriver
      ProTruckDriver
    S
    Fresh Face
    • Steven R
    • Author
    • Fresh Face
    • 3 replies
    • July 12, 2022

    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

    aqila
    Community Manager
    Forum|alt.badge.img+1
    • aqila
    • Community Manager
    • 29 replies
    • July 12, 2022

    Hi Steven,

    Yes please do DM me so we can investigate further.

    Thanks,

    Aqil

    Product Manager, Opentext
    ProTruckDriver
    TripleHelix
    2 people like this
    • ProTruckDriver
      ProTruckDriver
    • TripleHelix
      TripleHelix

    Reply


    Terms & Conditions