Tracing a weird exception on Azure AD B2C

PKua, Public domain, via Wikimedia Commons

The B2C error on the page is:

The page cannot be displayed because an internal server error has occurred.

The error in AppInsights is:

""Content"": "Web.TPEngine.StateMachineHandlers.SendErrorResponseToXmlHttpRequestClient"

There are no other details, attribute names etc., that could serve as clues.

To see how to use AppInsights, refer to this.

I previously wrote up some details here.

Since then, I’ve done some more research.

What you see going through the trace is:

“”EventName””: “”SELFASSERTED””,

“”StateName””: “”Microsoft.Cpim.Common.PolicyException””

“”Content””: “”Web.TPEngine.StateMachineHandlers.WarningExceptionTraceHandler””
},

and then the error.

I have only ever seen this error on a self-asserted page.

My educated guess is that this happens when B2C tries to render the page.

I created a test policy that:

• Get a users’ email — “Get-Email”
• Reads the user details — “AAD-UserReadUsingEmailAddress”
• Display some attributes — “SelfAsserted-HTML”

The error happens on the third step.

As usual, the policy that causes the error is in the gist.

If you look at the policy, you see:

<ClaimType Id="extension_a">    
    <DataType>string</DataType>   
</ClaimType>

and this is defined as a string. Given that this is an output field in a self-asserted page:

<OutputClaims>
      <OutputClaim ClaimTypeReferenceId="accountEnabled"/>
      <OutputClaim ClaimTypeReferenceId="givenName"/>
      <OutputClaim ClaimTypeReferenceId="surname"/>
      <OutputClaim ClaimTypeReferenceId="extension_a"/>
      <OutputClaim ClaimTypeReferenceId="extension_b"/>
</OutputClaims>

it should have an input type as well, so let’s add:

<UserInputType>TextBox</UserInputType>

to “extension_a” and “extension_b”.

No, same error.

What about “accountEnabled”, “givenName”, and “surname”?

“givenName” and “surname” are both defined with a “UserInputType” of “TextBox” in the base policy file, but “accountEnabled” is simply a string.

So using inheritance, let’s augment the definition:

<ClaimType Id="accountEnabled">
    <UserInputType>TextBox</UserInputType> 
</ClaimType>

and add “DisplayName” to the extensions for readability.

Bingo!

The page is finally displayed:

I then added:

<ClaimType Id="extension_dob">
    <DisplayName>Extension DoB</DisplayName>      
    <DataType>dateTime</DataType> 
    <UserInputType>TextBox</UserInputType>   
</ClaimType>

just to check a different data type, and again the error occurred until I added a TextBox.

The gist that displays correctly is here.

The trick is to look for reasons why the page can’t render!

All good!