401 UNAUTHORIZED when calling WorldCheck with name containing accents

Hi,

When calling the SEQ-screen-sync-individual: Perform Synchronous Screening: Individual API with a name containing accents, I have a 401 UNAUTHORIZED but when I call WorldCheck directly with Postman, I have a result. Is there something special to check with the encoding? I tried to change the encoding of the POST body with

For instance, when calling for "Stéphane Bern", I have the unauthorized answer. But without the accent "é", I have a result. The result seems to be the same than the one made with Postman. Are they in all case?

Thanks.

Find more posts tagged with

world-check-one

world-check

Accepted answers

Irfan.Khan

@cao-trung.do

You can avoid the issue by encoding the request payload as ‘utf-8’ and then use it to calculate the content length of the payload.

This is mandatory if the user is trying to screen names with special characters. This is done to properly calculate the content byte length and not the string length.

As per my understanding, it’s the length of the content/payload sent to the API which determines that the request will succeed or not, if your request contains special characters. Also, when the payload is being sent in the request, it has to be sent as UTF-8 encoded.

Please find the simplified steps to achieve the same below:

The content body should be converted to UTF-8.
Calculate the length of the UTF-8 encoded content. Putting it simply, the length of UTF-8 encoded content is different than the normal payload body.
Use the normal payload/content body in the dataToSign variable.
Use the content length of the UTF-8 encoded in the dataToSign variable.
Send the UTF-8 encoded content/payload in the API request.
Send the content length of the UTF-8 encoded in the request header.

I advise you to send the same request using Postman. If it is successful, check the authorization headers and the content length in it and make sure the authorization header and the content length you are sending via your code is also the same. This should give you a success response.

Please do not include “charset”=UTF-8 as headers while sending your request, this will not solve the problem. We do not expect the charset in the request and hence it will result in error.

Kindly let me know if this helps by accepting the answer.

All comments

Irfan.Khan

@cao-trung.do

You can avoid the issue by encoding the request payload as ‘utf-8’ and then use it to calculate the content length of the payload.

This is mandatory if the user is trying to screen names with special characters. This is done to properly calculate the content byte length and not the string length.

Please find the simplified steps to achieve the same below:

The content body should be converted to UTF-8.
Calculate the length of the UTF-8 encoded content. Putting it simply, the length of UTF-8 encoded content is different than the normal payload body.
Use the normal payload/content body in the dataToSign variable.
Use the content length of the UTF-8 encoded in the dataToSign variable.
Send the UTF-8 encoded content/payload in the API request.
Send the content length of the UTF-8 encoded in the request header.

Please do not include “charset”=UTF-8 as headers while sending your request, this will not solve the problem. We do not expect the charset in the request and hence it will result in error.

Kindly let me know if this helps by accepting the answer.

Pedro Lima

There is a simple way to fix this, you can change

payload.length()

payload.getBytes().length

on generateAuthHeaders implementation.

The content-length will be correct after this.

EXPLORE OUR SITES