Как узнать, что вызывает внутреннюю ошибку сервера Azure B2C 500?

Я пытаюсь добавить шаги оркестрации в свой путь пользователя Azure B2C IEF, однако, когда я вношу изменения, я часто получаю сообщение об ошибке: «500 — внутренняя ошибка сервера».

Я пытался использовать Application Insights, но это ничего не говорит об ошибке 500.

Вот мой технический профиль

    <TechnicalProfile Id="Step1">
      <DisplayName>Step 1</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="Email" Required="true"/>
        <OutputClaim ClaimTypeReferenceId="newPassword" Required="true" />
        <OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true" />
      </OutputClaims>
    </TechnicalProfile>

А вот и мой этап пути пользователя

    <OrchestrationStep Order="3" Type="ClaimsExchange">
      <Preconditions>
        <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
          <Value>objectId</Value>
          <Action>SkipThisOrchestrationStep</Action>
        </Precondition>
      </Preconditions>
      <ClaimsExchanges>
        <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="Step1" />
      </ClaimsExchanges>
    </OrchestrationStep>

Есть ли способ узнать, что вызывает эти 500 внутренних ошибок сервера?


person Christopher Norris    schedule 09.02.2019    source источник


Ответы (1)


ContentDefinition: технический профиль SelfAssertedAttributeProvider должен иметь ContentDefinition, указанный в разделе Metadata. Это отсутствует в вашем техническом профиле.

Выходные претензии:

В техническом профиле Step1 нет ValidationTechnicalProfile. Это может потенциально стать проблемой. Так как это OutputClaims, политика должна указывать способ создания значения для каждого из них (даже если во время выполнения оно может фактически не создаваться). Таким образом, OutputClaim должен иметь одно из трех:

  1. Укажите DefaultValue, что гарантирует, что оно будет иметь это значение после вызова TechnicalProfile.
  2. Укажите UserInputType в ClaimType в разделе ClaimsSchema, что указывает на то, что есть способ получить это значение от пользователя.
  3. Укажите его как OutputClaim из ValidationTechnicalProfile, что позволит другому провайдеру получить такое значение (например, из AD Graph или Rest API).

CryptographicKeys: SelfAssertedAttributeProvider TechnicalProfile также требуется раздел CryptographicKeys, в котором указывается ключ, используемый провайдером.

Я бы рекомендовал скопировать технический профиль из Starter Packs Github и измените их, так как они будут содержать все необходимые элементы.

(Тот факт, что служба возвращает 500, является ошибкой, и ее необходимо исправить.)

person Omer Iqbal    schedule 10.02.2019