13.0.2 missing UTF-8 support in Azure

[JEBailey]

Describe the bug?

Testing the latest release for UTF-8 correctness. We're still experiencing an issue where we aren't receiving the correct string from the User profile object. We have changed a test profile account to have the name the first name Árvíztűrő Tükörfúrógép and it's corrupted when we access it from the User object

What is expected to happen?

I expect to get the words Árvíztűrő Tükörfúrógép

What is the actual behavior?

the name is returned as ��rv��zt��r�� T��k��rf��r��g��p

Reproduction Steps?

• Use java SDK 13.0.2 to create a client object to Okta
• Change the first name on a profile to a multibyte string:
• Access the profile via the client and request the name from the User object.

You'll see that the name is corrupted.

Additional Information?

No response

Java Version

running jdk17 on an azure function. unsure of how to retrieve that output from the shell

SDK Version

13.0.2

OS version

PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

[arvindkrishnakumar-okta]

@JEBailey Thanks for posting! Will check and address this.

[arvindkrishnakumar-okta]

@JEBailey I checked this scenario and I find it working as expected (characters are encoded correctly).

I wrote a simple test (https://github.com/okta/okta-sdk-java/blob/master/integration-tests/src/test/groovy/com/okta/sdk/tests/it/UsersIT.groovy#L171-L193) that tests this and below is the snapshot of the debugger view:

Here's the console view:

[JEBailey]

Went back and continued research. So this is apparently environment specific. When we first ran into it there was an open issue with UTF8 support and we believed this was related.

This appears to be happening only in our Azure Function container and only with the Okta SDK. We're receiving Okta web hooks with the correct encoding, we're dealing with other services where we are decoding the UTF-8 value correctly. It's only within the context of the Okta SDK where we retrieve a User that the encoding appears to break

[JEBailey]

So apparently the Okta SDK is sensitive to the underlying default charset. For some reason that I will be raising with Microsoft, the default charset for the jvm is US ASCII. By setting the default charset to UTF8 the values were properly decoded. I'm good now. I'll leave this to your discretion to close.