Как отобразить ошибку, возвращенную из пользовательской конечной точки API REST на следующем шаге оркестровки?

Question

Исходя из этого вопроса ... конечная точка API REST проверяет внешнюю электронную почту IDP и возвращает ошибку в случае, если электронная почта недействительна.

return Content(HttpStatusCode.Conflict, new CustomResponseContent
{
    Version = "1.0.0",
    Status = (int)HttpStatusCode.Conflict,
    UserMessage = message
});

Теперь я хотел бы обнаружить эту ошибку и использовать ее в следующем OrchestrationStep, например:

<OrchestrationStep Order="3" 
  Type="ClaimsExchange">
  <ClaimsExchanges>
    <ClaimsExchange Id="REST-ValidateSignInEmail" 
      TechnicalProfileReferenceId="REST-ValidateSignInEmail" />
  </ClaimsExchanges>
</OrchestrationStep>

<!-- Taken from here: https://medium.com/the-new-control-plane/creating-an-error-page-for-an-azure-ad-b2c-custom-policy-flow-fb2692a3b50f -->
<OrchestrationStep Order="4" 
  Type="ClaimsExchange">
  <Preconditions>
    <Precondition Type="ClaimEquals" 
      ExecuteActionsIf="true">
      <Value>extension_Flag</Value>
      <Value>False</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
  </Preconditions>
  <ClaimsExchanges>
    <ClaimsExchange Id="SelfAssertedRegError" 
      TechnicalProfileReferenceId="SelfAsserted-RegError" />
  </ClaimsExchanges>
</OrchestrationStep>

Если шаг 3 возвращает конфликт, я хотел бычтобы показать сообщение об ошибке на шаге 4, используя пользовательскую страницу ошибки, реализованную, как описано здесь .

Я вижу этот шаг 4 выполняется на основе extension_Flag.

Можно ли как-нибудь получить и сохранить результат из REST-ValidateSignInEmail и использовать его во флаге для шага 4?

Примечание. По завершении выполнения пользовательской поездки в URL-адресе отображается следующая ошибка AADB2C. Это происходит из-за ошибки конечной точки REST API (409 - Конфликт) ...

https://mywebsite.azurewebsites.net/#error=server_error&error_description=AADB2C%3a+user%40gmail.com+is+not+valid.%0d%0aCorrelation+ID%7a+7777f77-7afd-7777-a777-7c77b7e77b7b%0d%0aTimestamp%7a+2019-11-09+14%3a40%3a57Z%0d%0a&state=7777c77a-77ad-414a-84df-3c131ed81ba7

Я хочу передать сообщение error_descriptionк шагу 4.

Answer 1

Я сделал это по-другому ... вместо того, чтобы возвращать статус Конфликта [409], я изменил конечную точку REST, чтобы получить OutputClaim, например:

<OutputClaims>
    <OutputClaim ClaimTypeReferenceId="extension_isEnabled" 
        PartnerClaimType="IsEnabled" DefaultValue="false"/>
    <OutputClaim ClaimTypeReferenceId="errorMessage" 
        PartnerClaimType="ErrorMessage"/>
</OutputClaims>

Таким образом, у меня естьпретензия для проверки на шаге 4. Обратите внимание, что я также возвращаю errorMessage от конечной точки. Это сообщение об ошибке будет позже передано в SelfAsserted-RegError Технический профиль.

В зависимости от проверки, выполненной в серверной части, extension_isEnabled получит True или False .

На шаге 4 мы проверяем extension_isEnabled:

<OrchestrationStep Order="4" 
                   Type="ClaimsExchange">
    <Preconditions>
        <Precondition Type="ClaimEquals" 
                      ExecuteActionsIf="true">
            <Value>extension_isEnabled</Value>
            <Value>True</Value>
            <Action>SkipThisOrchestrationStep</Action>
        </Precondition>
    </Preconditions>
    <ClaimsExchanges>
         <ClaimsExchange Id="SelfAssertedRegError" 
                         TechnicalProfileReferenceId="SelfAsserted-RegError" />
    </ClaimsExchanges>
</OrchestrationStep>

Шаг 4 будет выполняться только тогда, когда extension_isEnabled is false . Если это true , мы SkipThisOrchestrationStep и технический профиль SelfAsserted-RegError вообще не будут вызываться. Поток UserJourney продолжается, как и ожидалось.