Неожиданные символы при работе с ARM template для API management

В одном из сценариев автоматизации мне понадобилось "на лету" менять значения в шаблонах для нескольких API, которые в последствии разворачивались в другое окружение.

Неожиданно для себя я получил какое-то невменяемое сообщение об ошибке а-ля неопознанные команды и т.д. Сначала я заглянул в шаблон через Notepad, но ничего не обнаружил, однако, каково было моё удивление, когда я открыл тот же шаблон в Visual Studio Code.

Изменения производились через PowerShell скрипт и он был всему виной. Другого объяснения у меня не было. 

Происходила замена символа одинарной кавычки на код.

Очень интересно то, что кодированные кавычки появлялись уже после чтения файла, а не после его сохранения.

Проблема решилась достаточно банально.

Get-AzApiManagementPolicy не возвращает политику для области API при наличии параметра -ApiId

Краткая заметка о работе с PowerShell Cmdlets для API management.

Замечено, что команда Get-AzApiManagementPolicy -ApiId "<api_id"> -Context $apimContext может не вернуть ничего в случае, когда политика для конкретного API имеет конфигурацию по-умолчанию.

Стоит добавить что-либо разумное и команда начинает возвращать состав политики.

Неправильный артифакт может скачиваться с Bamboo при определённых обстоятельствах

Забавный баг обнаружился при работе с Google Chrome и Bamboo.

Несмотря на то, что был доступен новый артифакт размером в 1 МБ в пайплайне, браузер упорно скачивал старый в 5 МБ. Помогло только использование Incognito режима. Вероятно что-то с кэшем.

 

Smart Screen выдаёт "Publisher: Unknown" при попытке установить собранный MSI или Exe файл

Очень часто встречался с ситуацией, когда люди подписав MSI или EXE с помощью signtool.exe из Windows SDK жаловались на то, что Windows Smart Screen выдаёт в сообщении   "Publisher: Unknown".

Проблема решается достаточно легко даже для самоподписанного сертификата:

Вам необходимо, чтобы рабочая станция или сервер, где запускается ПО, доверяли сертификату подписи.

Ошибка "ServiceExists" при развёртывании Azure API management с помощью ARM template

Можно столкнуться с подобной проблемой при переразвёртывании окружений с помощью ARM templates.

Вызывается данная проблема из-за фунеционала "Soft delete" для сущностей APIM, который реализован в Azure. По умолчанию, удалённый объект сохраняется до 48 часов, чтобы его можно было восстановить, если удаление было случайным.

В тоже время, это мешает развернуть APIM  с таким же именем.

Решить эту проблему можно перейдя по ссылке API ниже и выполнив пару простых действий (указать регион, где был размещён APIM и его имя). Это API позволяет вычистить всё удалённые сущности.

https://docs.microsoft.com/en-us/rest/api/apimanagement/2020-06-01-preview/deletedservices/purge#code-try-0

Кстати, замечу, что для многих сервисов Azure есть разные интересные API,  которые могут помочь решить проблему, если az cli, PowerShell или портал не позволяют добиться желаемого.

Быстрые заметки #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  имеет те же операции, то будет вызвано исключение при попытке записать в один и тот же объект дважды.