Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этом разделе показано, как использовать пакет SDK серверного сервера .NET в ключевых сценариях мобильных приложений Службы приложений Azure. Пакет SDK для мобильных приложений Azure помогает работать с мобильными клиентами из приложения ASP.NET.
Подсказка
Пакет SDK для сервера .NET для мобильных приложений Azure — это открытый исходный код на сайте GitHub. Репозиторий содержит весь исходный код, включая весь набор модульных тестов пакета SDK для сервера и некоторые примеры проектов.
Справочная документация
Справочная документация по пакету SDK для сервера находится здесь: Справочник по .NET для мобильных приложений Azure.
Практическое руководство. Создание серверной части мобильного приложения .NET
Если вы запускаете новый проект, вы можете создать приложение службы приложений с помощью портала Azure или Visual Studio. Приложение Службы приложений можно запустить локально или опубликовать проект в мобильном приложении облачной службы приложений.
Если вы добавляете мобильные возможности в существующий проект, см. раздел "Скачать и инициализировать пакет SDK ".
Создание серверной части .NET с помощью портала Azure
Чтобы создать мобильную серверную часть службы приложений, либо выполните инструкции из краткого руководства, либо следуйте этим шагам.
Войдите в портал Azure.
Выберите +NEW>Web + Mobile>Mobile App, а затем укажите имя для серверной части вашего мобильного приложения.
Для группы ресурсоввыберите существующую группу ресурсов или создайте новую (используя то же имя, что и приложение).
Для плана службы приложенийвыбран план по умолчанию (в категории "Стандартный"). Можно также выбрать другой план или создать новый.
Параметры плана службы приложений определяют местоположение, функции, затраты и вычислительные ресурсы, связанные с вашим приложением. Для получения дополнительных сведений о планах службы приложений Azure и о том, как создать новый план в другой ценовой категории и в нужном расположении, см. подробный обзорпланов службы приложений Azure.
Выберите Создать. На этом шаге создается серверная часть мобильных приложений.
В области параметров для новой серверной части мобильных приложений выберите краткий запуск> платформы клиентского приложения >Подключить базу данных.
варианты

В области Добавление подключения к данным выберите База данных SQL>и нажмите Создать новую базу данных. Введите имя базы данных, выберите ценовую категорию и выберите Server. Эту новую базу данных можно использовать повторно. Если у вас уже есть база данных в том же расположении, можно выбрать Использовать существующую базу данных. Мы не рекомендуем использовать базу данных в другом расположении из-за затрат на пропускную способность и более высокую задержку.
В области Новый сервер введите уникальное имя сервера, в поле имя сервера, введите имя пользователя и пароль, выберите Разрешить службам Azure доступ к серверуи нажмите кнопку ОК. На этом шаге создается новая база данных.
В области Добавление подключения к данным выберите строку подключения, введите значения входа и пароля для базы данных и нажмите кнопку ОК.
Подождите несколько минут, пока база данных будет развернута успешно, прежде чем продолжить.
В колонке "Начало работы " в разделе "Создание API таблицы" выберите C# в качестве внутреннего языка. Щелкните "Скачать", извлеките сжатые файлы проекта на локальный компьютер и откройте решение в Visual Studio.
Создание серверной части .NET с помощью Visual Studio 2017
Установите рабочую среду Azure с помощью Установщика Visual Studio, чтобы публиковать проект мобильных приложений в Azure из Visual Studio. После установки пакета SDK создайте приложение ASP.NET, выполнив следующие действия.
- Откройте диалоговое окно "Новый проект " (из файла>нового>проекта...).
- Разверните Visual C# и выберите веб-сайт.
- Выберите ASP.NET веб-приложение (.NET Framework).
- Укажите имя проекта. Затем нажмите кнопку ОК.
- Выберите мобильное приложение Azure из списка шаблонов.
- Нажмите кнопку "ОК ", чтобы создать решение.
- Щелкните правой кнопкой мыши проект в обозревателе решений и выберите "Опубликовать...", а затем выберите "Служба приложений " в качестве целевого объекта публикации.
- Следуйте инструкциям по проверке подлинности и выбору новой или существующей службы приложений Azure для публикации.
Создание серверной части .NET с помощью Visual Studio 2015
Установите пакет SDK Azure для .NET (версия 2.9.0 или более поздней версии), чтобы создать проект мобильных приложений Azure в Visual Studio. После установки пакета SDK создайте приложение ASP.NET, выполнив следующие действия.
- Откройте диалоговое окно "Новый проект " (из файла>нового>проекта...).
- Разверните шаблоны>Visual C# и выберите веб-сайт.
- Выберите ASP.NET веб-приложение.
- Укажите имя проекта. Затем нажмите кнопку ОК.
- В разделе ASP.NET шаблонов 4.5.2 выберите мобильное приложение Azure. Убедитесь в возможности использовать облачный хостинг, чтобы создать мобильный сервер в облаке, на котором можно опубликовать этот проект.
- Нажмите кнопку ОК.
Практическое руководство. Скачивание и инициализация пакета SDK
Пакет SDK доступен в NuGet.org. Этот пакет включает базовые функциональные возможности, необходимые для начала работы с пакетом SDK. Чтобы инициализировать пакет SDK, необходимо выполнить действия в объекте HttpConfiguration .
Установка пакета SDK
Чтобы установить пакет SDK, щелкните правой кнопкой мыши проект сервера в Visual Studio, выберите "Управление пакетами NuGet", найдите пакет Microsoft.Azure.Mobile.Server и нажмите кнопку "Установить".
Инициализация проекта сервера
Серверный проект .NET инициализируется аналогично другим проектам ASP.NET через включение класса запуска OWIN. Убедитесь, что вы ссылаетесь на пакет Microsoft.Owin.Host.SystemWebNuGet. Чтобы добавить этот класс в Visual Studio, щелкните правой кнопкой мыши на проекте сервера и выберите Добавить>новый элемент, затем Веб>Общие>Класс запуска OWIN. Класс создается со следующим атрибутом:
[assembly: OwinStartup(typeof(YourServiceName.YourStartupClassName))]
В методе Configuration() класса запуска OWIN используйте объект HttpConfiguration для настройки среды мобильных приложений Azure.
В следующем примере инициализируется проект сервера без дополнительных функций:
// in OWIN startup class
public void Configuration(IAppBuilder app)
{
HttpConfiguration config = new HttpConfiguration();
new MobileAppConfiguration()
// no added features
.ApplyTo(config);
app.UseWebApi(config);
}
Чтобы включить отдельные функции, необходимо вызвать методы расширения в объекте MobileAppConfiguration перед вызовом ApplyTo. Например, следующий код добавляет маршруты по умолчанию ко всем контроллерам API, имеющим атрибут [MobileAppController] во время инициализации:
new MobileAppConfiguration()
.MapApiControllers()
.ApplyTo(config);
Быстрый запуск сервера в портале Azure вызывает UseDefaultConfiguration(). Это эквивалентно следующей настройке:
new MobileAppConfiguration()
.AddMobileAppHomeController() // from the Home package
.MapApiControllers()
.AddTables( // from the Tables package
new MobileAppTableConfiguration()
.MapTableControllers()
.AddEntityFramework() // from the Entity package
)
.AddPushNotifications() // from the Notifications package
.MapLegacyCrossDomainController() // from the CrossDomain package
.ApplyTo(config);
Используются методы расширения:
-
AddMobileAppHomeController()предоставляет домашнюю страницу мобильных приложений Azure по умолчанию. -
MapApiControllers()предоставляет пользовательские возможности API для контроллеров WebAPI, украшенных атрибутом[MobileAppController]. -
AddTables()предоставляет сопоставление конечных точек/tablesс контроллерами таблиц. -
AddTablesWithEntityFramework()— это сокращение для сопоставления конечных точек/tablesс помощью контроллеров, использующих Entity Framework. -
AddPushNotifications()предоставляет простой метод регистрации устройств для Центров уведомлений. -
MapLegacyCrossDomainController()предоставляет стандартные заголовки CORS для локальной разработки.
Расширения ПАКЕТА SDK
Следующие пакеты расширений на основе NuGet предоставляют различные мобильные функции, которые могут использоваться приложением. Расширения можно включить во время инициализации с помощью объекта MobileAppConfiguration.
- Microsoft.Azure.Mobile.Server.Quickstart Поддерживает базовую настройку мобильных приложений. Добавлена в конфигурацию путем вызова метода расширения UseDefaultConfiguration во время инициализации. Это расширение включает следующие расширения: уведомления, проверка подлинности, сущность, таблицы, междоменные и домашние пакеты. Этот пакет используется в учебном пособии по мобильным приложениям, доступном на портале Azure.
- Microsoft.Azure.Mobile.Server.Home реализует страницу по умолчанию, которая указывает, что это мобильное приложение работает, для корня веб-сайта. Добавьте в конфигурацию, вызвав метод расширения AddMobileAppHomeController.
- Microsoft.Azure.Mobile.Server.Tables включает классы для работы с данными и настройки конвейера данных. Добавьте в конфигурацию, вызвав метод расширения AddTables.
- Microsoft.Azure.Mobile.Server.Entity позволяет Entity Framework получать доступ к данным в базе данных SQL. Добавьте в конфигурацию путем вызова метода расширения AddTablesWithEntityFramework.
- Microsoft.Azure.Mobile.Server.Authentication Обеспечивает аутентификацию и настройку ПО промежуточного слоя OWIN, используемого для проверки маркеров. Добавьте в конфигурацию, вызвав методы расширения AddAppServiceAuthentication и IAppBuilder.UseAppServiceAuthentication.
- Microsoft.Azure.Mobile.Server.Notifications включает push-уведомления и определяет конечную точку регистрации push-уведомлений. Добавьте в конфигурацию, вызвав метод расширения AddPushNotifications.
- Microsoft.Azure.Mobile.Server.CrossDomain Создает контроллер, который предоставляет данные устаревшим веб-браузерам вашего мобильного приложения. Добавьте в конфигурацию, вызвав метод расширения MapLegacyCrossDomainController.
- Microsoft.Azure.Mobile.Server.Login предоставляет метод AppServiceLoginHandler.CreateToken(), который является статическим методом, используемым во время пользовательских сценариев проверки подлинности.
Инструкция по: публикация проекта сервера
В этом разделе описывается, как опубликовать ваш backend-проект .NET с помощью Visual Studio. Вы также можете развернуть внутренний проект с помощью Git или любого из других методов, доступных там.
В Visual Studio перестройте проект для восстановления пакетов NuGet.
В обозревателе решений щелкните проект правой кнопкой мыши, щелкните Опубликовать. При первой публикации нужно определить профиль публикации. Если у вас уже есть профиль, его можно выбрать и нажать кнопку "Опубликовать".
Если вам будет предложено выбрать целевой объект публикации, нажмите кнопку "Служба приложений> Microsoft Azureдалее", а затем (при необходимости) войдите с учетными данными Azure. Visual Studio загружает и безопасно сохраняет параметры публикации непосредственно из Azure.

Выберите подписку, выберите тип ресурса в представлении, разверните мобильное приложение и щелкните серверную часть мобильного приложения, а затем нажмите кнопку "ОК".

Проверьте сведения о профиле публикации и нажмите кнопку "Опубликовать".

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

Как определить контроллер таблицы
Определите контроллер таблицы для предоставления таблицы SQL мобильным клиентам. Настройка контроллера таблицы требует трех шагов.
- Создайте класс объекта передачи данных (DTO).
- Настройте ссылку на таблицу в классе Mobile DbContext.
- Создайте контроллер таблицы.
Объект передачи данных (DTO) — это обычный объект C#, наследуемый от EntityData. Рассмотрим пример.
public class TodoItem : EntityData
{
public string Text { get; set; }
public bool Complete {get; set;}
}
DTO используется для определения таблицы в базе данных SQL. Чтобы создать запись базы данных, добавьте DbSet<> свойство в объект DbContext, который вы используете. В шаблоне проекта по умолчанию для мобильных приложений Azure DbContext называется Models\MobileServiceContext.cs.
public class MobileServiceContext : DbContext
{
private const string connectionStringName = "Name=MS_TableConnectionString";
public MobileServiceContext() : base(connectionStringName)
{
}
public DbSet<TodoItem> TodoItems { get; set; }
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Conventions.Add(
new AttributeToColumnAnnotationConvention<TableColumnAttribute, string>(
"ServiceColumnTable", (property, attributes) => attributes.Single().ColumnType.ToString()));
}
}
Если у вас установлен пакет SDK Для Azure, теперь можно создать контроллер таблицы шаблонов следующим образом:
- Щелкните правой кнопкой мыши папку "Контроллеры" и выберите "Добавить>контроллер...".
- Выберите параметр контроллера таблицы мобильных приложений Azure , а затем нажмите кнопку "Добавить".
- В диалоговом окне добавления контроллера :
- В раскрывающемся списке Model class выберите новый DTO.
- В раскрывающемся списке DbContext выберите класс DbContext для мобильной службы.
- Имя для контроллера создано для вас.
- Нажмите кнопку Добавить.
Проект сервера быстрого запуска содержит пример простого TodoItemController.
Как настроить размер страниц таблицы
По умолчанию мобильные приложения Azure возвращают 50 записей на запрос. Постраничная загрузка гарантирует, что клиент не блокирует поток пользовательского интерфейса и сервер слишком долго, обеспечивая хороший пользовательский опыт. Чтобы изменить размер страниц таблицы, увеличьте "разрешенный размер запроса" на стороне сервера и размер страницы на стороне клиента. "Разрешенный размер запроса" настраивается с помощью атрибута EnableQuery.
[EnableQuery(PageSize = 500)]
Убедитесь, что PageSize совпадает с размером, запрошенным клиентом. Подробнее о изменении размера страницы клиента смотрите в специальной клиентской документации HOWTO.
Практическое руководство. Определение пользовательского контроллера API
Пользовательский контроллер API предоставляет самые основные функциональные возможности серверной части мобильного приложения, предоставляя конечную точку. Вы можете зарегистрировать контроллер API для мобильных устройств с помощью атрибута [MobileAppController]. Атрибут MobileAppController регистрирует маршрут, настраивает сериализатор JSON для мобильных приложений и включает проверку версий клиента.
В Visual Studio щелкните правой кнопкой мыши папку "Контроллеры", а затем нажмите кнопку "Добавить> контроллер", выберите контроллер веб-API 2 — пустой и нажмите кнопку "Добавить".
Укажите имя контроллера, например
CustomControllerи нажмите кнопку "Добавить".В новом файле класса контроллера добавьте следующую инструкцию using:
using Microsoft.Azure.Mobile.Server.Config;Примените атрибут [MobileAppController] к определению класса контроллера API, как показано в следующем примере:
[MobileAppController] public class CustomController : ApiController { //... }В файле App_Start/Startup.MobileApp.cs добавьте вызов метода расширения MapApiControllers , как показано в следующем примере:
new MobileAppConfiguration() .MapApiControllers() .ApplyTo(config);
Вы также можете использовать метод UseDefaultConfiguration() вместо MapApiControllers(). К любому контроллеру, который не применяется MobileAppControllerAttribute , по-прежнему можно получить доступ к клиентам, но он может быть неправильно использован клиентами с помощью любого клиентского пакета SDK для мобильных приложений.
Как работать с аутентификацией
Мобильные приложения Azure используют проверку подлинности и авторизацию службы приложений для защиты серверной части мобильных устройств. В этом разделе показано, как выполнять следующие задачи, связанные с проверкой подлинности, в проекте серверного сервера .NET:
- Практическое руководство. Добавление проверки подлинности в серверный проект
- Практическое руководство. Использование пользовательской проверки подлинности для приложения
- Практическое руководство. Получение сведений о пользователе, прошедших проверку подлинности
- Практическое руководство. Ограничение доступа к данным для авторизованных пользователей
Практическое руководство. Добавление проверки подлинности в серверный проект
Вы можете добавить проверку подлинности в проект сервера, расширив объект MobileAppConfiguration и настроив ПО промежуточного слоя OWIN. При установке пакета Microsoft.Azure.Mobile.Server.Quickstart и вызове метода расширения UseDefaultConfiguration можно перейти к шагу 3.
В Visual Studio установите пакет Microsoft.Azure.Mobile.Server.Authentication.
В файле проекта Startup.cs добавьте следующую строку кода в начале метода Configuration :
app.UseAppServiceAuthentication(config);Этот компонент промежуточного ПО OWIN проверяет токены, выданные соответствующим шлюзом службы приложений.
Добавьте атрибут
[Authorize]к любому контроллеру или методу, требующим проверки подлинности.
Сведения о проверке подлинности клиентов в серверной части мобильных приложений см. в статье "Добавление проверки подлинности в приложение".
Практическое руководство. Использование пользовательской проверки подлинности для приложения
Это важно
Чтобы включить пользовательскую проверку подлинности, необходимо сначала включить проверку подлинности службы приложений без выбора поставщика для службы приложений на портале Azure. Это позволит включить переменную среды WEBSITE_AUTH_SIGNING_KEY при размещении.
Если вы не хотите использовать один из поставщиков проверки подлинности и авторизации службы приложений, вы можете реализовать собственную систему входа. Установите пакет Microsoft.Azure.Mobile.Server.Login, чтобы помочь в создании маркера проверки подлинности. Укажите собственный код для проверки учетных данных пользователя. Например, можно проверить наличие соленых и хэшированных паролей в базе данных. В приведенном ниже примере метод isValidAssertion() (определенный в другом месте) отвечает за эти проверки.
Пользовательская проверка подлинности делается доступной путем создания ApiController и открытия register и login действий. Клиент должен использовать пользовательский интерфейс для сбора сведений от пользователя. Затем сведения передаются в API с помощью стандартного вызова HTTP POST. После проверки утверждения с помощью метода AppServiceLoginHandler.CreateToken() будет выдан токен.
ApiController не должен использовать атрибут [MobileAppController].
Пример действия login:
public IHttpActionResult Post([FromBody] JObject assertion)
{
if (isValidAssertion(assertion)) // user-defined function, checks against a database
{
JwtSecurityToken token = AppServiceLoginHandler.CreateToken(new Claim[] { new Claim(JwtRegisteredClaimNames.Sub, assertion["username"]) },
mySigningKey,
myAppURL,
myAppURL,
TimeSpan.FromHours(24) );
return Ok(new LoginResult()
{
AuthenticationToken = token.RawData,
User = new LoginResultUser() { UserId = userName.ToString() }
});
}
else // user assertion was not valid
{
return this.Request.CreateUnauthorizedResponse();
}
}
В предыдущем примере LoginResult и LoginResultUser являются сериализуемыми объектами, предоставляющими необходимые свойства. Клиент ожидает, что ответы входа будут возвращены в виде объектов JSON формы:
{
"authenticationToken": "<token>",
"user": {
"userId": "<userId>"
}
}
Метод AppServiceLoginHandler.CreateToken() включает параметр аудитории и параметр издателя. Оба этих параметра устанавливаются на URL-адрес корневого каталога вашего приложения, с использованием протокола HTTPS. Аналогичным образом необходимо задать secretKey значение ключа подписи приложения. Не распределяйте ключ подписи в клиенте, так как его можно использовать для создания ключей и выдачи себя за пользователей. Ключ подписи можно получить во время размещения в службе приложений, ссылаясь на переменную среды WEBSITE_AUTH_SIGNING_KEY . При необходимости в локальном контексте отладки следуйте инструкциям в разделе Локальная отладка с проверкой подлинности, чтобы получить ключ и сохранить его в качестве параметра приложения.
Выданный маркер также может включать другие утверждения и дату окончания срока действия. Как минимум, выданный токен должен содержать утверждение о субъекте (sub).
Вы можете поддерживать стандартный метод loginAsync() клиента, перегрузив маршрут проверки подлинности. Если клиент вызывает client.loginAsync('custom'); для входа, маршрут должен быть /.auth/login/custom. Можно задать маршрут для пользовательского контроллера проверки подлинности с помощью MapHttpRoute():
config.Routes.MapHttpRoute("custom", ".auth/login/custom", new { controller = "CustomAuth" });
Подсказка
Использование подхода loginAsync() гарантирует, что токен аутентификации прикрепляется к каждому последующему вызову службы.
Практическое руководство. Получение сведений о пользователе, прошедших проверку подлинности
При проверке подлинности пользователя службой приложений вы можете получить доступ к назначенному идентификатору пользователя и другим сведениям в серверном коде .NET. Сведения о пользователе можно использовать для принятия решений об авторизации в серверной части. Следующий код получает идентификатор пользователя, связанный с запросом:
// Get the SID of the current user.
var claimsPrincipal = this.User as ClaimsPrincipal;
string sid = claimsPrincipal.FindFirst(ClaimTypes.NameIdentifier).Value;
Идентификатор безопасности является производным от идентификатора пользователя для конкретного поставщика и является статическим для данного пользователя и поставщика входа. SID равно NULL для недействительных токенов аутентификации.
Служба приложений также позволяет запрашивать определенные утверждения от поставщика услуг аутентификации. Каждый поставщик удостоверений может предоставить дополнительные сведения с помощью пакета SDK поставщика удостоверений. Например, вы можете использовать API Graph Facebook для сведений о друзьях. Вы можете указать утверждения, запрашиваемые в колонке поставщика на портале Azure. Для некоторых утверждений требуется дополнительная конфигурация с поставщиком удостоверений.
Следующий код вызывает метод расширения GetAppServiceIdentityAsync для получения учетных данных для входа, которые включают маркер доступа, необходимый для выполнения запросов к API Graph Facebook:
// Get the credentials for the logged-in user.
var credentials =
await this.User
.GetAppServiceIdentityAsync<FacebookCredentials>(this.Request);
if (credentials.Provider == "Facebook")
{
// Create a query string with the Facebook access token.
var fbRequestUrl = "https://graph.facebook.com/me/feed?access_token="
+ credentials.AccessToken;
// Create an HttpClient request.
var client = new System.Net.Http.HttpClient();
// Request the current user info from Facebook.
var resp = await client.GetAsync(fbRequestUrl);
resp.EnsureSuccessStatusCode();
// Do something here with the Facebook user information.
var fbInfo = await resp.Content.ReadAsStringAsync();
}
Добавьте инструкцию using для System.Security.Principal, чтобы задействовать метод расширения GetAppServiceIdentityAsync.
Практическое руководство. Ограничение доступа к данным для авторизованных пользователей
В предыдущем разделе мы показали, как получить идентификатор пользователя прошедшего проверку подлинности. Вы можете ограничить доступ к данным и другим ресурсам на основе этого значения. Например, добавление столбца userId в таблицы и фильтрация результатов запроса по идентификатору пользователя — это простой способ ограничить возвращаемые данные только авторизованным пользователям. Следующий код возвращает строки данных, только если идентификатор безопасности соответствует значению в столбце UserId в таблице TodoItem:
// Get the SID of the current user.
var claimsPrincipal = this.User as ClaimsPrincipal;
string sid = claimsPrincipal.FindFirst(ClaimTypes.NameIdentifier).Value;
// Only return data rows that belong to the current user.
return Query().Where(t => t.UserId == sid);
Метод Query() возвращает IQueryable, которые можно управлять с помощью LINQ для обработки фильтрации.
Практическое руководство. Добавление push-уведомлений в проект сервера
Добавьте push-уведомления в проект сервера, расширив объект MobileAppConfiguration и создав клиент Центров уведомлений.
В Visual Studio щелкните правой кнопкой мыши проект сервера и выберите пункт "Управление пакетами NuGet", найдите
Microsoft.Azure.Mobile.Server.Notificationsи нажмите кнопку "Установить".Повторите этот шаг, чтобы установить пакет
Microsoft.Azure.NotificationHubs, который включает в себя клиентскую библиотеку Центров уведомлений.В файле App_Start/Startup.MobileApp.cs добавьте вызов метода расширения AddPushNotifications() во время инициализации:
new MobileAppConfiguration() // other features... .AddPushNotifications() .ApplyTo(config);Добавьте следующий код, который создает клиент Центров уведомлений:
// Get the settings for the server project. HttpConfiguration config = this.Configuration; MobileAppSettingsDictionary settings = config.GetMobileAppSettingsProvider().GetMobileAppSettings(); // Get the Notification Hubs credentials for the Mobile App. string notificationHubName = settings.NotificationHubName; string notificationHubConnection = settings .Connections[MobileAppSettingsKeys.NotificationHubConnectionString].ConnectionString; // Create a new Notification Hub client. NotificationHubClient hub = NotificationHubClient .CreateClientFromConnectionString(notificationHubConnection, notificationHubName);
Теперь можно использовать клиент Центров уведомлений для отправки push-уведомлений на зарегистрированные устройства. Дополнительные сведения см. в разделе "Добавление push-уведомлений" в приложение. Дополнительные сведения о центрах уведомлений см. в разделе "Обзор центров уведомлений".
Практическое руководство. Включение целевой принудительной отправки с помощью тегов
Центры уведомлений позволяют отправлять целевые уведомления определенным регистрациям с помощью тегов. Несколько тегов создаются автоматически:
- Идентификатор установки определяет определенное устройство.
- Идентификатор пользователя на основе аутентифицированного SID определяет конкретного пользователя.
Идентификатор установки можно получить из свойства installationId в MobileServiceClient. В следующем примере показано, как использовать идентификатор установки для добавления тега в определенную установку в Центрах уведомлений:
hub.PatchInstallation("my-installation-id", new[]
{
new PartialUpdateOperation
{
Operation = UpdateOperationType.Add,
Path = "/tags",
Value = "{my-tag}"
}
});
Все теги, предоставленные клиентом во время регистрации push-уведомлений, игнорируются серверной частью при создании установки. Чтобы клиент мог добавлять теги в установку, необходимо создать пользовательский API, который добавляет теги с помощью предыдущего шаблона.
См. теги push-уведомлений, добавленных клиентом в образце завершенного быстрого запуска "Мобильные приложения службы приложений" для примера.
Практическое руководство. Отправка push-уведомлений пользователю, прошедшему проверку подлинности
Когда прошедший проверку подлинности пользователь регистрирует push-уведомления, в регистрацию автоматически добавляется тег идентификатора пользователя. С помощью этого тега можно отправлять push-уведомления всем устройствам, зарегистрированным этим человеком. Следующий код получает SID пользователя, выполняющего запрос, и отправляет шаблонное push-уведомление каждой регистрации устройства для этого человека.
// Get the current user SID and create a tag for the current user.
var claimsPrincipal = this.User as ClaimsPrincipal;
string sid = claimsPrincipal.FindFirst(ClaimTypes.NameIdentifier).Value;
string userTag = "_UserId:" + sid;
// Build a dictionary for the template with the item message text.
var notification = new Dictionary<string, string> { { "message", item.Text } };
// Send a template notification to the user ID.
await hub.SendTemplateNotificationAsync(notification, userTag);
При регистрации push-уведомлений от клиента, прошедшего проверку подлинности, убедитесь, что проверка подлинности завершена перед попыткой регистрации. Для получения дополнительной информации см. "Отправка пользователям" в готовом примере краткого руководства для мобильных приложений службы приложений App Service с серверной частью на .NET.
Практическое руководство. Отладка и устранение неполадок пакета SDK для .NET Server
Служба приложений Azure предоставляет несколько методов отладки и устранения неполадок для ASP.NET приложений:
- Мониторинг службы приложений Azure
- Включение ведения журнала диагностики в Службе приложений Azure
- устранение неполадок службы приложений Azure в Visual Studio
Лесозаготовка
Журналы диагностики службы приложений можно записывать с помощью трассировки в ASP.NET. Перед записью в журналы необходимо включить диагностику в серверной части мобильного приложения.
Чтобы включить диагностику и запись в журналы, выполните следующие действия.
Выполните действия, описанные в разделе Включение ведения журнала приложений (Windows).
Добавьте следующую инструкцию using в файл кода:
using System.Web.Http.Tracing;Создайте трассировщик для записи данных из бэкэнда .NET в журналы диагностики следующим образом:
ITraceWriter traceWriter = this.Configuration.Services.GetTraceWriter(); traceWriter.Info("Hello, World");Повторно опубликуйте проект сервера и получите доступ к серверной части мобильного приложения, чтобы выполнить определенный путь кода с включенным ведением журнала.
Скачайте и оцените журналы, как описано в файлах журналов Access.
Локальная отладка с проверкой подлинности
Вы можете запустить приложение локально, чтобы протестировать изменения перед их публикацией в облаке. Для большинства серверных компонентов мобильных приложений Azure нажмите клавишу F5 в Visual Studio. Однако при использовании проверки подлинности существуют некоторые дополнительные рекомендации.
У вас должно быть облачное мобильное приложение с настроенной проверкой подлинности и авторизацией службы приложений, а клиент должен иметь облачную конечную точку, указанную в качестве альтернативного узла входа. Ознакомьтесь с документацией по клиентской платформе для конкретных шагов, необходимых.
Убедитесь, что в вашей мобильной серверной части установлен Microsoft.Azure.Mobile.Server.Authentication. Затем в классе OWIN запуска вашего приложения добавьте следующее после того, как MobileAppConfiguration был применен к HttpConfiguration:
app.UseAppServiceAuthentication(new AppServiceAuthenticationOptions()
{
SigningKey = ConfigurationManager.AppSettings["authSigningKey"],
ValidAudiences = new[] { ConfigurationManager.AppSettings["authAudience"] },
ValidIssuers = new[] { ConfigurationManager.AppSettings["authIssuer"] },
TokenHandler = config.GetAppServiceTokenHandler()
});
В предыдущем примере необходимо настроить параметры приложения authAudience и authIssuer в файле Web.config таким образом, чтобы каждый из них был URL-адресом корневого приложения в формате HTTPS. Аналогичным образом необходимо задать authSigningKey значение ключа подписи приложения. Чтобы получить ключ подписи, выполните следующие действия.
- Перейдите к приложению на портале Azure
- Щелкните "Сервис", Kudu, Go.
- На сайте управления Kudu щелкните Среда.
- Найдите значение для WEBSITE_AUTH_SIGNING_KEY.
Используйте ключ подписи для параметра authSigningKey в конфигурации локального приложения. Теперь серверная часть мобильного приложения готова к проверке токенов при локальном запуске, которые клиент получает из облачной конечной точки.