Быстрые заметки #4: Azure B2C custom policies

Забавное поведение "склеивания" или наследования замечено для technical profiles в Azure B2C.

К примеру, у меня есть два MultiSelect Checkbox. Если я полностью определяю technical profile в TFE.xml для получения пользовательского ввода, то Checkbox будет внизу страницы, т.к. перед ними будут идти другие claims.

Но если я использую механизм наследования, когда из TFB.xml технический профайл наследуется TFE.xml, где содержаться 4 дополнительных клейма и Checkbox, то Checkbox уедут вверх формы.

UPDATE #1 Очень интересно, но похоже проблема самоустранилась. Не думаю, что это кэш браузера, т.к. использовался Incognito режим. Что-то влияло на поведение формы... Может быть CSS, который применялся для создания надписи внизу формы.

UPDATE #2 Помучил нашего веб-девелопера, оказывается, для того, чтобы решить проблему пришлось гвоздями прибить Check-box в CSS к нижней грани:

.terms-and-policy {​​​​​​​

margin-top: 150px;

margin-bottom: -20px;

font-weight: 600;

}​​​​​​​

li.CheckboxMultiSelect {​​​​​​​

left: 45px;

right: 45px;

}​​​​​​​

li.CheckboxMultiSelect input ~ label {​​​​​​​

margin-right: 30px;

}​​​​​​​

li.CheckboxMultiSelect:nth-of-type(1) {​​​​​​​

position: absolute;

bottom: 130px;

}​​​​​​​

li.CheckboxMultiSelect:nth-of-type(2) {​​​​​​​

position: absolute;

bottom: 70px;

}​​​​​​

Так что, поведение без CSS будет, как описано выше.

Быстрые заметки #3: Azure B2C custom policies

Если вы хотите добавит MultiSelect Checkbox на singup экран (к примеру, для получения согласия пользователя с условиями использования системы), обратите внимание на забавный нюанс:

Checkbox могут не появится на экране, если технический профайл AAD-UserWriteUsingLogonEmail случайно был настроен так, что содержит одни и теже claims в секциях PersistedClaims и OutputClaims этого профайла. 

Для решения проблемы удалите claims из секции OutputClaims.

К примеру:

            <!-- ToU Claims   -->

            <PersistedClaim ClaimTypeReferenceId="extension_termsOfUseConsentChoice" />

            <PersistedClaim ClaimTypeReferenceId="extension_termsOfUseConsentVersion"/>

          

            <!-- Pp Claims    -->

            <PersistedClaim ClaimTypeReferenceId="extension_ppConsentChoice" />

            <PersistedClaim ClaimTypeReferenceId="extension_ppConsentVersion"/>

Аналогичные claims  "extension_termsOfUseConsentChoice", "extension_termsOfUseConsentVersion","extension_ppConsentChoice","extension_ppConsentVersion" содержаться в <OutputClaims></OutputClaims>.

Пример конфигурации MultiSelect Checkbox:

      <!-- Claims related to user ToU consent - versions based -->

      <ClaimType Id="extension_termsOfUseConsentChoice">

        <DisplayName></DisplayName>

        <DataType>string</DataType>

        <UserInputType>CheckboxMultiSelect</UserInputType>

        <Restriction>

          <Enumeration Text=" I agree to the Terms Of Service" Value="AgreeToTermsOfUseConsentYes" SelectByDefault="false" />

        </Restriction>

      </ClaimType>  

Быстрые заметки #2: Azure B2C custom policies

Если пытаться переопределись поведение для  PasswordReset или ProfileEdit User Journeys, поместив изменённый journey в TrustedFrameworkExtensions.xml, то можно столкнуться с ошибкой ниже:

Validation failed: 2 validation error(s) found in policy "B2C_1A_TRUSTFRAMEWORKEXTENSIONS" of tenant "myTenant.onmicrosoft.com".User journey "ProfileEdit" in policy "B2C_1A_TrustFrameworkExtensions" of tenant "myTenant.onmicrosoft.com" has step 3 with 2 claims exchanges. It must be preceded by a claims provider selection in order to determine which claims exchange can be used.User journey "ProfileEdit" in policy "B2C_1A_TrustFrameworkExtensions" of tenant "myTenant.onmicrosoft.com" has step 4 with 2 claims exchanges. It must be preceded by a claims provider selection in order to determine which claims exchange can be used.User journey "ProfileEdit" in policy "B2C_1A_TrustFrameworkExtensions" of tenant "myTenant.onmicrosoft.com" has step 3 with 2 claims exchanges. It must be preceded by a claims provider selection in order to determine which claims exchange can be used.User journey "ProfileEdit" in policy "B2C_1A_TrustFrameworkExtensions" of tenant "myTenant.onmicrosoft.com" has step 4 with 2 claims exchanges. It must be preceded by a claims provider selection in order to determine which claims exchange can be used.

Возникает она из-за того, что journey с аналогичным именем присутствует в TrustedFrameworkBase.xml.

Чтобы ошибка ушла переименуйте user journey в TrustedFrameworkExtensions.xml и Relying party policy.

Такой подход позволит сохранить user journeys, доступные по умолчанию, но и получить желаемое поведение от модифицированного. 

Что использовать при проверке переменной: $Null или $Variable.count -eq 0 - мысли в слух

Забавная ситуация произошла достаточно давно: один скрипт не отрабатывал ветвление из-за проваленной проверки на $Null в переменной. 

Проверка всегда выдавала ложное значение, т.к. старый софт на другой стороне возвращал какую-то ересь - скрытый символ (на экране ничего нет, если сделать Write-host  и т.д., а переменная непустая).

В общем, не вдаваясь в детали, помогло выражение "$Variable.count -eq 0".

Может кого спасёт.

Быстрые заметки #1: Azure B2C custom policies

Как известно, custom policies в Azure B2C представляют собой набор xml файлов, который состоит из 3-х частей:

• Trusted Framework Base - базовая политика (далее - TFB);
• Trusted Framework Extension - расширение базовой политики (далее - TFE);
• Relying Party policy - политика для конкртеного IdP (Identity Provider), этого добра может быть много.

TFB базовая и наследуется всеми, но её значения могут быть предопределены в TFE, RP.

Тут есть нюанс: 

если случайно вы создадите technical profile (далее - TP) в TFE, который будет иметь аналогичное имя с TP в TFB и полный цикл жизни для claims поступающих на вход, их трансформацию, проверку, запись и т.д., то вы можете получить сообщение а-ля "пользователь уже существует" и обнаружить, что действительно - пользователь создан.

Причина

Судя по всему , т.к. TP будет вызван 2 раза (условно, или операции с claims будут суммированы), ибо имя одинаково и TP в TFE  имеет те же операции, то будет вызвано исключение при попытке записать в один и тот же объект дважды.