Broker xamarin что это

Xamarin.Messaging.Broker хочет получить доступ через брандмауэр

После установки VS2019 16.5.1 и 16.5.2 я получаю сообщение о том, что Защитник Windows заблокировал некоторые функции, Xamarin.Messaging.Broker и спрашивает, следует ли мне это разрешить.

Обычно я, как кажется, являюсь частью Visual Studio, но этот исполняемый файл находится в моем файле appdata \ local \ temp, чего я бы не ожидал. Поиск в сети информации об этом дает мало полезной информации.

Кто-нибудь знает, что он делает и с какой стати вы бы поместили exe в локальный пользователь временный?

Мое сообщение появляется точно после обновления 16.5.0 до 16.5.3. Мы все видим это сообщение в версии 16.5.2 и выше.

Итак, насколько нам известно, это произошло из-за того, что Microsoft добавила что-то новое в 16.5.2 и выше. Это не может быть ничем иным, кроме работы Microsoft, поскольку мы все видели это сообщение брандмауэра.

Мой файл находился в C: \ users \ username \ appdata \ local \ temp \ xamarin \ xma \ broker.local \ 16.5.000.533 \ broker.exe

Этот доступ добавит запись в расширенные «Входящие правила» брандмауэра, что означает предоставление доступа извне к нашим компьютерам по протоколу UDP / TCP.

Вывод :

Лично я разрешил этот файл в брандмауэре, потому что у меня куча проблем в xamarin (специально для подключения к Mac), и я не хочу добавлять больше, я предлагаю всем вам сделать то же самое.

Подробно о Xamarin

Вы неплохо владеете языком C# и платформой .NET в целом? Вам надоело стоять в стороне и смотреть, как кто-то другой пишет крутые мобильные приложения вместо вас? У меня есть для вас кое-что интересное! То, что поможет вам изменить сложившуюся ситуацию и позволит писать отличные мобильные приложения, не требуя отдельного изучения Objective-C и Java. Я расскажу вам о продукте Xamarin. Подробно и правдиво.

Что это?

Xamarin — это фреймворк для кроссплатформенной разработки мобильных приложений (iOS, Android, Windows Phone) с использованием языка C#. Идея очень простая. Вы пишете код на своем любимом языке, с применением всех привычных для вас языковых фич типо LINQ, лямбда-выражений, Generic`ов и async`ов. При этом вы имеете полный доступ ко всем возможностям SDK платформы и родному механизму создания UI, получая на выходе приложение, которое, строго говоря, ничем не отличается от нативных и (по крайней мере по заверениям) не уступает им в производительности.

• Xamarin.IOS — библиотека классов для C#, предоставляющая разработчику доступ к iOS SDK;
• Xamarin.Android — библиотека классов для C#, предоставляющая разработчику доступ к Android SDK;
• Компиляторы для iOS и Android;
• IDE Xamarin Studio;
• Плагин для Visual Studio.

Давай подробнее

Некоторое время назад достаточно широкую известность получили ряд фреймворков(например PhoneGap), которые предлагают разработку кроссплатформенных мобильных приложений на HTML5 с использованием JavaScript. Идея заключается в том, что приложение разрабатывается как обычный сайт для мобильных устройств с использованием соответствующих js-библиотек, например, Jquery Mobile. Затем все это упаковывается в некий контейнер, который для пользователя выглядит как нативное приложение. Минусы этих фреймворков очевидны: во-первых, вы не имеете доступа к нативным элементам UI. То есть даже если вы хотите использовать стандартную кнопку «Назад» для iPhone, вы должны ее нарисовать и сверстать. Во-вторых, вы получаете урезанный и обобщенный API для работы с платформой. Таким образом, те или иные фичи, присущие какой-то отдельной платформе будут вам недоступны. Ну и третье и самое важное — такое приложение физически запускается внутри браузера телефона (точнее внутри контрола WebView). Не нужно расписывать долго, что это значит: низкая производительность (особенно «хорош» WebView на старых версиях Android) и огромные проблемы с отображением (ну, господа, это же — браузер). Хотя, конечно, в определенных случаях эти фреймворки могут оказаться очень уместны.

Xamarin — это про другое. Т.к. я надеюсь, что мы здесь все — неглупые пацаны разработчики, я расскажу о том, как он устроен внутри. Это позволит понять потенциал данной технологии. Xamarin основан на open-source реализации платформы .NET — Mono. Эта реализация включает в себя собственный компилятор C#, среду выполнения, а так же основные .NET библиотеки. Цель проекта — позволить запускать программы, написанные на C#, на операционных системах, отличных от Windows — Unix-системах, Mac OS и других. Важно, что разработкой Xamarin занимаются те же люди, что и разработкой Mono. И (тут внимание) — это НЕ Microsoft со всеми вытекающими плюсами и минусами.

С точки зрения исполнения приложений между iOS и Android есть одно ключевое различие — способ их предварительной компиляции. Как известно, для выполнения приложений в Android используется виртуальная Java-машина Dalvik. Нативные приложения, которые пишутся на Java, компилируются в некий промежуточный байт-код, который интерпретируется Dalvik`ом в команды процессора в момент исполнения программы(т.е. аналогично тому, как работает CLR в .NET). Это так называемая Just-in-time компиляция (компиляция на лету). В iOS используется другая модель компиляции — Ahead-of-Time (компиляция перед исполнением). Xamarin учитывает это различие, предоставляя отдельные компиляторы для каждой из этих платформ, которые позволяют на выходе получать настоящие, нативные приложения, которые выполняются вне контекста браузера и могут использовать все аппаратные и программные ресурсы платформы.
Для iOS ситуация простая — никакой виртуальной машины нет и программный код должен быть просто заранее скомпилирован в машинный. Для этой цели используется AOT компилятор Mono.
Для Android интереснее. При компиляции приложения происходит перевод кода на C# в промежуточный байт-код, понятный виртуальной машине Mono и сама эта виртуальная машина также добавляется в упакованное приложение. И Mono и Dalvik написаны на Си и работают поверх ядра Linux (а мы помним, что Android основана на Linux). Вы уже понимаете, что происходит. При запуске приложения на Android обе виртуальные машины начинают работать бок о бок и обмениваются данными через специальный механизм wrapper`ов.

Это все хорошо, но давай ближе к разработке

Расскажу подробнее о самих библиотеках на примере Xamarin.iOS (Monotouch), т.к. опыта работы с ней гораздо больше, чем с Xamarin.Android (но там все аналогично).
Библиотека классов Monotouch.dll предоставляет доступ ко всем возможностям iOS SDK. Для разработчика — это просто набор C#-классов с хорошей аннотацией. Внутри эти классы используют разработанные инженерами Xamarin механизмы биндинга на нативные классы и методы. Важно, что этот же механизм можно использовать для биндинга любых библиотек, написанных на objective-c. Большинство классов и методов называются так же, как в оригинальном iOS SDK, хотя бывают исключения (в этом случае приходится использовать поиск в документации Xamarin по оригинальному названию, т.к. оно фигурирует в атрибутах биндинга). В классах активно используется механизм C# event`ов, что позволяет писать красивый и компактный код обработчиков с использованием лямбда-выражений:

Да и в целом код, написанный на C# выглядит гораздо читабельней и приятней. Посмотрите разницу на примере кода, создающего строку с атрибутами:

Для асинхронной разработки Xamarin предоставляет возможность использовать как классы из пространства имен System.Threading.Thread и System.Threading.ThreadPool, так и полный спектр возможностей, предоставляемых Task Parallel Library. Использование последней, однако, считается предпочтительным. Кроме того, на момент написания статьи вышла очередная Stable версия, в которой появилась поддержка .NET 4.5, в частности, теперь можно использовать ключевые слова async/await. Хотя эта возможность была доступна и ранее, но для этого приходилось использовать beta-канал обновлений.

Что с ограничениями?

Ограничения в Xamarin.iOS связаны в основном с тем, что в iOS, как было сказано выше, в отличии от .NET и Mono нет виртуальной машины. Поэтому возникают трудности с поддержкой Generic. Причина ясна — на компилятор ложится задача проанализировать код и определить все возможные конкретизации в том или ином классе и методе. Отсюда возникают такие ограничения:

• Не рекомендуется использовать Virtual Generic методы, т.к компилятор не всесилен и может не учесть все возможные варианты использования;
• Нельзя создавать Generic-наследников от класса NSObject, который является базовым в иерархии Objective-C. Достаточно серьезное ограничение, которое может некоторым образом испортить вашу стройную и красивую архитектуру.

Разработка UI

Для каждой платформы Xamarin предоставляет возможность использовать нативные средства разработки UI и нативные элементы пользовательского интерфейса. Для Android создание UI может происходить непосредственно в коде или же при помощи декларативного подхода с описанием интерфейса в XML. Для iOS это также либо код, либо использование нативных средств проектирования интерфейса — отдельные xib-файлы или же один большой Storyboard. Редактирование этих файлов происходит в привычной для iOS-разработчика среде XCode. И это означает, что вам потребуется Mac. Да, для разработки iOS-приложений вам в любом случае потребуется Mac по двум причинам:
Во-первых, как я уже сказал, для редактирования UI в среде XCode. Во-вторых, для отладки приложений требуется симулятор iPhone/iPad, который также доступен только на Mac.

Переносимость кода

Xamarin, по заявлениям разработчиков, является средством кроссплатформенной разработки, т.е. ожидаемо, что приложение, написанное один раз, может быть запущено на различных мобильных платформах. Но, в этом случае возникает конфликт с предыдущим пунктом. Как же так?

На самом деле ситуация обстоит следующим образом. Для каждой из платформы вам потребуется реализовать собственный слой UI. Т.е код, который отвечает за внешний вид приложения, вам придется написать для каждой платформы отдельно. Это цена за возможность использования нативных механизмов работы с UI. Если разбивать приложение на слои, то получается такая схема:

• Data Layer (DL) – Хранилище данных, например, база SqlLite или xml-файлы;
• Data Access Layer (DAL) – Обертка над хранилищем для осуществления CRUD-операций;
• Business Layer (BL) – Слой, содержащий бизнес-логику приложения;
• Service Access Layer (SAL) – Слой, отвечающий за взаимодействие с удаленными сервисами (Rest, Json, WCF);
• Application Layer (AL) – Слой, содержащий платформозависимый код, другими словами, это код, который зависит от библиотек monotouch.dll или monodroid.dll;
• User Interface Layer (UI) – Слой пользовательского интерфейса.

Сторонние компоненты

У Xamarin существует собственный магазин сторонних компонентов Xamarin Components.Он интегрируется в IDE и позволяет в несколько кликов подключать к вашему проекту различные компоненты, написанные как инженерами Xamarin, так и сторонними разработчиками. Количество компонентов, кстати, растет как на дрожжах. Есть как платные, так и бесплатные(на данный момент их большинство). Все компоненты можно разделить на две части. Одни предоставляют дополнительные элементы пользовательского интерфейса, другие являются библиотеками классов. Например вариант для Mono известной библиотеки для работы с Json — Json.NET или же библиотека для взаимодействия с Rest-сервисами — RestSharp. Не все компоненты кроссплатформенные, многие доступны только для конкретной платформы. Как я упоминал выше, Xamarin использует механизм биндингов для связывания с нативными библиотеками классов, что позволяет портировать на C# любые нативные библиотеки классов. Кроме того, для Xamarin.iOS, например, существует специальная утилита, которая умеет генерировать такие биндинги автоматически. Собственно это позволяет инженерам Xamarin поспевать за всеми нововведениями iOS. Так, в частности, в Xamarin.iOS практически сразу после выхода появилась возможность использовать Dropbox API, а так же новые фичи iOS 7.

Документация и комьюнити

Xamarin имеет отличную документацию, содержащую подробные руководства, сниппеты, а также внушительную базу примеров. Документация непосредственно по всем классам библиотек Monotouch и Monodroid являются частью общей документации Mono. Но, к сожалению, этого все равно недостаточно, чтобы покрыть весь пласт вопросов, которые могут возникать в процессе разработки. У Xamarin существует комьюнити разработчиков, которое сконцентировано на официальном форуме и на StackOverlow. Активностью и инициативностью людей в комьюнити похвастаться не могу. Из пяти вопросов, заданных на официальном форуме, ответ я получил только на один. Может быть, не то спрашивал. В этом плане неоценимую помощь оказала приватная тех. поддержка с инженерами по электронной почте, доступная в business-лицензии. Отвечают, как правило, в течении нескольких часов и не стандартными отписками «попробуйте выключить и включить», а действительно разбираются в проблеме и помогают ее решить. Следует понимать, что база вопросов и ответов, накопленная для нативной разработки гораздо шире, чем для Xamarin, поэтому, как бы вы ни хотели, вам придется разобраться в специфическом синтаксисе objective-c (c Java проблем быть не должно), чтобы понимать примеры кода на том же StackOverflow. Кроме того, это откроет вам доступ к прочтению и пониманию официальной документации для платформы, что на определенном этапе может стать очень важно. С другой стороны, в этом есть и положительный момент: получив такой базис, вам будет проще перейти к нативной разработке при необходимости.

Среда разработки

Разработчики Xamarin в качестве среды разработки предлагают использовать либо собственную IDE — Xamarin Studio, либо Visual Studio (в business-лицензии, об этом ниже).

Xamarin Studio

• Приятная подсветка синтаксиса;
• Автодополнение кода (включая возможность одновременного импорта namespaces);
• Удобный универсальный поиск по названиям файлов, типам, членам классов и т.п;
• Развитые возможности навигации по проекту: Быстрый переход к описанию класса, переход к базовому классу, список мест использования класса и т.д.;
• Различные механизмы рефакторинга и быстрая подсказка (как alt+Enter в Resharper);
• Достаточно развитые механизмы дебага, включая слежение, просмотр текущего значения переменной при наведении, визуализацию потоков и аналог Immediate window в VS;
• Встроенная интеграция с системами контроля версий: SVN, Git и TFS (для TFS, правда, нужны сторонние утилиты);

• Горячие клавиши (включая copy-paste) работают только в английской раскладке. Разработчикам известно об этой проблеме. Баг в багтрекере заведен;
• Периодически, при попытке поставить breakpoint студия виснет. Несмотря на наличие механизма автосохранения, это немного расстраивает.
• При использовании встроенной интеграции с SVN добавление новых файлов в проект не отслеживается автоматически. Т.е. изменение в файле .csproj зачекинятся, а сами файлы — нет. По каждому файлу нужно кликать правой кнопкой и добавлять его в репозиторий. Техподдержка сообщила, что им известно об этом баге и они исправят его в одном из ближайших обновлений.
• Иногда проект перестает компилироваться. Лечится перезапуском студии.

Visual Studio

Xamarin предлагает возможность вести разработку в Visual Studio после установки специального плагина, который доступен в business-лицензии (на момент выхода статьи — 999$), но есть месяц триала. Плюсы очевидны: вы становитесь разработчиком мобильных приложений, не меняя места дислокации, и можете использовать всю тяжелую артиллерию в лице Resharper и других ваших любимых плагинов. После установки плагина для Visual Studio вам потребуется настроить соединение с вашим Mac, которое будет использовано при запуске проекта на выполнение. Т.е. после запуска, приложение автоматически пересылается на Mac, где компилируется и загружается либо на симулятор либо на устройство, при этом сам процесс процесс отладки, расстановка брейкпоинтов и т.д. будет происходить в Visual Studio.
Вариантов работы в Visual Studio несколько. Либо вы используется виртуальную машину внутри Mac (например Parallels), куда ставите Windows и Visual Studio. Либо используете две разные физические машины, при этом использовать один Mac для нескольких PC-разработчиков затруднительно, т.к. отладка требует манипуляций с симулятором. И последний вариант — использовать виртуальную машину с Mac OS X (так называемый hackintosh). Вполне себе жизнеспособный вариант, хотя и есть некоторые ограничения. Например, в Xcode придется перемещаться по Storyboard только с использованием полос прокрутки, т.к. windows-мышь не очень похожа на настоящую мышь от Mac со всеми вытекающими.

Время горькой правды. С отладкой в Visual Studio периодически возникали проблемы. Самая заметная — это то, что при удаленной сборке приложения, процесс отладки мог отвалиться по таймауту. Хотя, опять же, стоит отдать должное разработчикам — они исправляют ошибки достаточно интенсивно, и вот уже на момент написания этой статьи, процесс отладки стал стабильным. Хотя и стоит заметить, что на текущий момент, времени между запуском приложения и появлением его на экране симулятора при использовании Visual Studio требуется несколько больше, чем при использовании Xamarin Studio на Mac.

Лицензии

На момент написания статьи Xamarin имеет следующие типы лицензий:

• Starter — Бесплатно. Рассчитан скорее для ознакомления, т.к. имеет ограничение на размер приложения (по ощущениям очень не большой, т.к. не компилировались даже некоторые sample-проекты) и на использование сторонних компонентов;
• Indie — 299$ на одно рабочее место. Снимается ограничение на размер приложения. Разработка возможна только в Xamarin Studio;
• Business — 999$ на одно рабочее место. Появляется возможность разработки в Visual Studio и приватная тех. поддержка от инженеров Xamarin;
• Enterprise -1899$ на одно рабочее место. В рамках этой лицензии предоставляется возможность получения Hotfixes (не вижу особого смысла, т.к. обновления и так выходят очень часто), а так же возможность отправить инженерам проект с исходным кодом и сказать «Что-то у меня не получается поменять ширину ячейки в таблице, помогите!». Плюс ряд не слишком полезных, на мой взгляд, опций.

Заключение

На текущий момент технология Xamarin является серьезным инструментом для решения сложных задач в области разработки мобильных приложений. Несмотря на это, команда разработчиков не останавливается и продолжает его активное развитие и улучшение. За последние два месяца заметны серьезные улучшения в общей стабильности продукта. На мой взгляд у технологии большое будущее и с каждым днем число разработчиков, использующих ее в качестве основного фреймворка для разработки будет неуклонно расти. Однако довольно высокая стоимость лицензии может стать препятствием для использования на пути indie-разработчиков. В целом свой опыт работы с данным фреймворком считаю положительным и продолжу его использование.

Использование Microsoft Authenticator или корпоративного портала Intune в приложениях Xamarin

В Android и iOS такими брокерами, как Microsoft Authenticator и корпоративный портал Microsoft Intune для Android, обеспечивается:

• Единый вход (SSO) . Пользователям не потребуется входить в каждое приложение.
• Идентификация устройства. Брокер получает доступ к сертификату устройства. Этот сертификат создается на устройстве при его подключении к рабочему месту.
• Проверка идентификации приложения. Когда приложение вызывает брокер, ему передается URL-адрес перенаправления. Брокер выполняет проверку URL-адреса.

Чтобы включить одну из этих функций, используйте параметр WithBroker() при вызове метода PublicClientApplicationBuilder.CreateApplication . Для параметра .WithBroker() по умолчанию задается значение true.

Настройка проверки подлинности через брокер в библиотеке проверки подлинности Майкрософт для .NET (MSAL.NET) зависит от платформы:

Проверка подлинности через брокер для iOS

Чтобы разрешить взаимодействие приложения Xamarin.iOS с приложением Microsoft Authenticator, выполните следующие действия. Если вы ориентируетесь на iOS 13, рекомендуем ознакомиться с критическими изменениями API компании Apple.

Шаг 1. Включение поддержки брокера

Необходимо включить поддержку брокера для отдельных экземпляров PublicClientApplication . По умолчанию поддержка отключена. При создании PublicClientApplication с помощью PublicClientApplicationBuilder используйте параметр WithBroker() , как показано в следующем примере. Для параметра WithBroker() по умолчанию задается значение true.

Шаг 2. Разрешение доступа к цепочке ключей

Чтобы разрешить доступ к цепочке ключей, необходимо иметь группу доступа к цепочке ключей для приложения. При создании приложения можно использовать API WithIosKeychainSecurityGroup() для настройки группы доступа к цепочке ключей:

Дополнительные сведения см. в разделе Разрешение доступа к цепочке ключей.

Шаг 3. Обновление AppDelegate для обработки обратного вызова

Когда MSAL.NET вызывает брокер, он отправляет обратный вызов в приложение с помощью метода OpenUrl класса AppDelegate . Так как MSAL ожидает ответ от брокера, приложение должно взаимодействовать для отправки обратного вызова в MSAL.NET. Для обеспечения такого взаимодействия обновите файл AppDelegate.cs, чтобы переопределить следующий метод.

Этот метод вызывается при каждом запуске приложения. Его использование дает возможность обработать ответ от брокера и завершить процесс проверки подлинности, запущенный MSAL.NET.

Шаг 4. Настройка UIViewController()

Находясь в файле AppDelegate.cs, установите окно объекта. Обычно для Xamarin iOS устанавливать окно объекта не требуется, но оно необходимо для отправки и получения ответов от брокера.

Чтобы настроить окно объекта, выполните следующие действия:

В файле AppDelegate.cs задайте App.RootViewController в новом UIViewController() . Это назначение гарантирует включение UIViewController в вызов брокеру. Если этот параметр назначен неправильно, может появиться следующее сообщение об ошибке:

"uiviewcontroller_required_for_ios_broker":"UIViewController is null, so MSAL.NET cannot invoke the iOS broker. See https://aka.ms/msal-net-ios-broker"

В вызове AcquireTokenInteractive используйте .WithParentActivityOrWindow(App.RootViewController) , а затем передайте ссылку в окно объекта, которое вы будете использовать.

В вызове AcquireToken :

Шаг 5. Регистрация схемы URL-адресов

MSAL.NET использует URL-адреса для вызова брокера и для последующего возврата ответа брокера в приложение. Чтобы завершить круговой путь, зарегистрируйте схему URL-адресов для приложения в файле Info.plist.

Имя CFBundleURLSchemes должно включать msauth. в качестве префикса. После префикса используйте CFBundleURLName .

В схеме URL-адресов BundleId является уникальным идентификатором приложения: $"msauth.(BundleId)" . Таким образом, если для BundleId задано значение com.yourcompany.xforms , то схема URL-адресов будет msauth.com.yourcompany.xforms .

Эта схема URL-адресов становится частью URI перенаправления, который является уникальным идентификатором вашего приложения при получении ответа брокера.

Шаг 6. Добавление идентификатора брокера в раздел LSApplicationQueriesSchemes

MSAL использует –canOpenURL: для проверки того, установлен ли брокер на устройстве. В iOS 9 компания Apple заблокировала схемы, которые может запрашивать приложение.

Добавьте msauthv2 в раздел LSApplicationQueriesSchemes файла Info.plist, как показано в следующем примере:

Шаг 7. Добавление URI перенаправления в регистрацию приложения

При использовании брокера к URI перенаправления выдвигается дополнительное требование. URI перенаправления должен иметь следующий формат:

Ниже приведен пример:

Обратите внимание, что URI перенаправления совпадает с именем CFBundleURLSchemes , включенным в файл Info.plist.

Добавьте URI перенаправления в регистрацию приложения на портале Azure. Чтобы создать URI перенаправления, имеющий правильный формат, используйте Регистрацию приложений на портале Azure для создания URI перенаправления через брокер из идентификатора пакета.

Для создания URI перенаправления выполните следующие действия:

Выберите Azure Active Directory>Регистрация приложений> ваше зарегистрированное приложение.

Выберите Проверка подлинности>Добавить платформу>iOS / macOS.

Введите идентификатор пакета и нажмите Настроить.

Скопируйте созданный URI перенаправления, который отображается в текстовом поле URI перенаправления, для включения в код:

Нажмите Готово, чтобы завершить создание URI перенаправления.

Проверка подлинности через брокер для Android

Шаг 1. Включение поддержки брокера

Поддержка брокера включается отдельно для каждого PublicClientApplication . Она отключена по умолчанию. При создании IPublicClientApplication с помощью PublicClientApplicationBuilder используйте параметр WithBroker() (по умолчанию ему задано значение true).

Шаг 2. Обновление AppDelegate для обработки обратного вызова

Когда MSAL.NET вызывает брокер, тот, в свою очередь, отправляет обратный вызов в приложение с использованием метода OnActivityResult() . Так как MSAL будет ждать ответ от брокера, приложению необходимо направить результат в MSAL.NET.

Направьте результат в метод SetAuthenticationContinuationEventArgs(int requestCode, Result resultCode, Intent data) , переопределив метод OnActivityResult() , как показано ниже:

Этот метод вызывается каждый раз при запуске приложения брокера, и его использование дает возможность обработки ответа от брокера и завершения процесса проверки подлинности, запущенного MSAL.NET.

Шаг 3. Задание действия

Чтобы включить проверку подлинности через брокер, настройте действие таким образом, чтобы MSAL могла отправлять и получать ответ от брокера. Для этого укажите действие (обычно MainActivity ) для родительского объекта WithParentActivityOrWindow(object parent) .

Например, в вызове для AcquireTokenInteractive() :

Шаг 4. Добавление URI перенаправления в регистрацию приложения

MSAL использует URL-адреса для вызова брокера и для последующего возврата ответа в приложение. Чтобы завершить круговой путь, зарегистрируйте URI перенаправления для приложения с помощью портала Azure.

Формат URI перенаправления для приложения зависит от сертификата, используемого для подписи APK. Пример:

Последняя часть URI, hgbUYHVBYUTvuvT&Y6tr554365466= — это версия сигнатуры в кодировке Base64, с помощью которой подписывается APK. Если при разработке приложения в Visual Studio отладка кода осуществляется без подписи APK с помощью определенного сертификата, Visual Studio подписывает для вас APK в целях отладки. Когда Visual Studio подписывает APK для вас таким способом, компьютеру, на котором выполняется его сборка, предоставляется уникальная подпись. Таким образом, каждый раз при сборке приложения на другом компьютере необходимо обновлять URI перенаправления в коде приложения и регистрацию приложения на портале Azure для проверки подлинности с помощью MSAL.

При отладке можно столкнуться с исключением MSAL (или сообщением журнала), сообщающим, что указанный URI перенаправления неверен. Исключение или сообщение журнала также указывает URI перенаправления, который следует использовать с компьютером, где в данный момент выполняется отладка. Вы можете использовать указанный URI перенаправления, чтобы продолжить разработку приложения при условии обновления URI перенаправления в коде и добавления предоставленного URI перенаправления в регистрацию приложения на портале Azure.

Когда вы будете готовы финализировать код, обновите URI перенаправления в коде и регистрацию приложения на портале Azure, чтобы использовать подпись сертификата, с помощью которого подписываются APK.

На практике это означает, что следует добавить URI перенаправления для каждого члена вашей команды разработчиков, а также URI перенаправления для версии APK, подписанной для рабочей среды.

Вы можете вычислить подпись самостоятельно аналогично тому, как это делает MSAL:

Вы также можете получить подпись для пакета, используя keytool с помощью следующих команд:

• Windows:
• macOS:

Шаг 5 (необязательно). Возврат в системный браузер

Если MSAL настроен для использования брокера, но брокер не установлен, MSAL вернется к использованию веб-представления (браузера). MSAL попытается пройти проверку подлинности с помощью системного браузера по умолчанию на устройстве, что завершится ошибкой, так как URI перенаправления настроен для использования брокера, а системному браузеру не известно, как использовать его для возврата в MSAL. Чтобы избежать этой ошибки, можно настроить фильтр намерений с помощью URI перенаправления брокера, который использовался на шаге 4.

Измените манифест приложения, чтобы добавить фильтр намерений:

Например, если у вас есть URI перенаправления для msauth://com.microsoft.xforms.testApp/hgbUYHVBYUTvuvT&Y6tr554365466= , манифест должен выглядеть как следующий фрагмент кода XML.

Перед подписью в значении android:path требуется косая черта ( / ).

Дополнительные сведения о настройке приложения для системного браузера и поддержки Android 11 см. в разделе Обновление манифеста Android для поддержки системного браузера.

В качестве альтернативы можно настроить MSAL для возврата во встроенный браузер, который не зависит от URI перенаправления:

Советы по устранению неполадок при проверке подлинности через брокер в Android

Ниже приведены несколько советов по предотвращению проблем при внедрении проверки подлинности через брокер в Android:

URI перенаправления: добавьте URI перенаправления в регистрацию приложения на портале Azure. Отсутствующий или неверный URI перенаправления является распространенной проблемой, с которой сталкиваются разработчики.

Версия брокера: установите минимально необходимую версию приложений брокера. Для проверки подлинности через брокер в Android можно использовать одно из этих двух приложений.

(версия 5.0.4689.0 или более поздняя) (версия 6.2001.0140 или более поздняя).

Приоритет брокера: при установке нескольких брокеров MSAL взаимодействует с первым установленным на устройстве брокером.

Например, если сначала установить Microsoft Authenticator, а затем — корпоративный портал Intune, то проверка подлинности через брокер будет выполняться только с помощью Microsoft Authenticator.

Журналы: при возникновении проблемы с проверкой подлинности через брокер просмотр журналов брокера может помочь в диагностике причины.

Получение журналов Microsoft Authenticator:

1. Нажмите кнопку меню в правом верхнем углу приложения.
2. Выберите Отправить отзыв>Возникли проблемы? .
3. Под вопросом Что вы пытаетесь сделать? выберите вариант и добавьте описание.
4. Чтобы отправить журналы, нажмите стрелку в правом верхнем углу приложения.

После отправки журналов в диалоговом окне отобразится идентификатор инцидента. Запишите идентификатор инцидента и укажите его, обращаясь за помощью.

Получение журналов корпоративного портала Intune:

1. Нажмите кнопку меню в левом верхнем углу приложения.
2. Выберите Справка>Написать в поддержку.
3. Чтобы отправить журналы, выберите Отправить только журналы.

После отправки журналов в диалоговом окне отобразится идентификатор инцидента. Запишите идентификатор инцидента и укажите его, обращаясь за помощью.