пятница, 23 апреля 2021 г.

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

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

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



 

понедельник, 22 марта 2021 г.

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

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

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

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










среда, 10 марта 2021 г.

Ошибка "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 или портал не позволяют добиться желаемого.

пятница, 19 февраля 2021 г.

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

понедельник, 15 февраля 2021 г.

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