Encoding Issues in B2C Custom Policies

Question

We are facing encoding issues in our B2C custom policies, even after updating all ContentDefinition DataUri to the latest templates. The problems arise in the signinup and password reset custom policies, where characters like "ä" are not rendering correctly. Also each XML file is provided with the encoding="utf-8".

Upon token verification in the signinup functionality, an email is sent, and upon opening the window for entering the two passwords, I noticed that the HTML page contains the UTF-8 meta tag for encoding. However, when inspecting the body of the received HTML page via the Chrome debugbar, I observed that the encoding issue is already present. Instead of rendering the "ä" character, it displays a weird question mark symbol.

Additionally, I noticed a change in the URL structure during this process. The URL changes from "B2C_1A_SignInUp/api/SelfAsserted/unified" to "B2C_1A_SignInUp/api/SelfAsserted/confirmed." I suspect that this URL change might be related to a template switch, possibly causing the encoding issue.

I would greatly appreciate any insights or solutions to resolve this encoding problem in my B2C custom policies. Thank you in advance for your assistance.

Answer 1

Hi @Teun Dozeman ,

Thanks for reaching out.

I'm glad that you were able to resolve your issue and thank you for posting your solution so that others experiencing the same thing can easily reference this! Since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others", I'll repost your solution in case you'd like to "Accept" the answer.

For such issues, It is important to ensure consistency in encoding declaration is present in all relevant XML files, from the creation and modification of policy shell scripts to their deployment. By explicitly specifying UTF-8 encoding where necessary, you can avoid rendering issues with special characters and ensure proper handling of text data.

Thanks,

Shweta

Answer 2

The issue was in the deploy/building pipeline scripts. When reading the XML files and sending i forced everywhere to use UTF-8 encoding since i think the default is ASCII. This fixed the issue for me