Utiliser le Kit de développement logiciel (SDK) du serveur principal .NET pour Azure Mobile Apps

Article
10/01/2016

back-end .NET
Node.js back-office

Cette rubrique vous montre comment utiliser le Kit de développement logiciel (SDK) du serveur principal .NET dans les scénarios Azure App Service Mobile Apps clés. Le Kit de développement logiciel (SDK) Azure Mobile Apps vous aide à utiliser des clients mobiles à partir de votre application ASP.NET.

Conseil / Astuce

Le kit SDK de serveur .NET pour Azure Mobile Apps est open source sur GitHub. Le référentiel contient tout le code source, y compris l’ensemble de la suite de tests unitaires du Kit de développement logiciel (SDK) serveur et certains exemples de projets.

Documentation de référence

La documentation de référence pour le SDK serveur se trouve ici : Référence .NET pour Azure Mobile Apps.

Guide pratique pour créer un back-end d’application mobile .NET

Si vous démarrez un projet, vous pouvez créer une application App Service à l’aide du portail Azure ou de Visual Studio. Vous pouvez exécuter l’application App Service localement ou publier le projet sur votre application mobile App Service basée sur le cloud.

Si vous ajoutez des fonctionnalités mobiles à un projet existant, consultez la section Télécharger et initialiser le KIT de développement logiciel (SDK) section.

Créer un back-end .NET à l’aide du portail Azure

Pour créer un back-end mobile App Service, suivez le didacticiel de démarrage rapide ou procédez comme suit :

Connectez-vous sur le portail Azure à.
Sélectionnez +NEW>Web + Mobile>Mobile App, puis indiquez un nom pour le back-end de vos applications mobiles.
Pour groupe de ressources, sélectionnez un groupe de ressources existant ou créez-en un (en utilisant le même nom que votre application).
Pour le plan App Service , le plan par défaut (dans le niveau Standard ) est sélectionné. Vous pouvez également sélectionner un autre plan, ou créer un autre plan.

Les paramètres du plan App Service déterminent l’emplacement , les fonctionnalités, le coût et les ressources de calcul associées à votre application. Pour plus d’informations sur les plans App Service et sur la création d’un plan dans un autre niveau tarifaire et dans votre emplacement souhaité, consultez vue d’ensemble détaillée des plans Azure App Service.
Sélectionnez Créer. Cette étape crée le back-end Mobile Apps.
Dans le volet paramètres du nouveau serveur principal Mobile Apps, sélectionnez démarrage rapide> votre plateforme d’application cliente >connecter une base de données.

sélections
Dans le volet Ajouter une connexion de données, sélectionnez base de données SQL>Créer une base de données. Entrez le nom de la base de données, choisissez un niveau tarifaire, puis sélectionnez Server. Vous pouvez réutiliser cette nouvelle base de données. Si vous disposez déjà d’une base de données dans le même emplacement, vous pouvez choisir à la place Utiliser une base de données existante. Nous vous déconseillons d’utiliser une base de données dans un autre emplacement, en raison des coûts de bande passante et d’une latence plus élevée.
Dans le volet Nouveau serveur, entrez un nom de serveur unique dans la zone nom du serveur, fournissez une connexion et un mot de passe, sélectionnez Autoriser les services Azure à accéder au serveur, puis sélectionnez OK. Cette étape crée la nouvelle base de données.
De retour dans le volet Ajouter une connexion de données, sélectionnez chaîne de connexion, entrez le nom d'utilisateur et le mot de passe de votre base de données, puis sélectionnez OK.

Attendez quelques minutes que la base de données soit déployée avec succès avant de continuer.

De retour dans le panneau Prise en main, sous Créer une API de table, choisissez C# comme langage back-end . Cliquez sur Télécharger, extrayez les fichiers projet compressés sur votre ordinateur local et ouvrez la solution dans Visual Studio.

Créer un back-end .NET à l’aide de Visual Studio 2017

Installez la charge de travail Azure via Visual Studio Installer pour publier sur le projet Azure Mobile Apps à partir de Visual Studio. Une fois que vous avez installé le Kit de développement logiciel (SDK), créez une application ASP.NET en procédant comme suit :

Ouvrez la boîte de dialogue Nouveau projet (à partir de Fichier>Nouveau>Projet...).
Développez Visual C# et sélectionnez Web.
Sélectionnez ASP.NET application web (.NET Framework).
Renseignez le nom du projet. Cliquez ensuite sur OK.
Sélectionnez Azure Mobile App dans la liste des modèles.
Cliquez sur OK pour créer la solution.
Cliquez avec le bouton droit sur le projet dans l’Explorateur de solutions , puis choisissez Publier..., puis choisissez App Service comme cible de publication.
Suivez les invites pour vous authentifier et choisir un nouveau ou existant Azure App Service à publier.

Créer un back-end .NET à l’aide de Visual Studio 2015

Installez le kit de développement logiciel (SDK) Azure pour .NET (version 2.9.0 ou ultérieure) pour créer un projet Azure Mobile Apps dans Visual Studio. Une fois que vous avez installé le Kit de développement logiciel (SDK), créez une application ASP.NET en procédant comme suit :

Ouvrez la boîte de dialogue nouveau projet (à partir de Fichier>Nouveau projet de>...).
Développez Modèles>Visual C#, puis sélectionnez Web.
Sélectionnez Application Web ASP.NET.
Renseignez le nom du projet. Cliquez ensuite sur OK.
Sous modèles ASP.NET 4.5.2, sélectionnez Azure Mobile App. Vérifiez le Host dans le cloud pour créer un backend mobile dans le cloud où vous pourrez publier ce projet.
Cliquez sur OK.

Guide pratique pour télécharger et initialiser le Kit de développement logiciel (SDK)

Le Kit de développement logiciel (SDK) est disponible sur NuGet.org. Ce package inclut les fonctionnalités de base requises pour commencer à utiliser le Kit de développement logiciel (SDK). Pour initialiser le Kit de développement logiciel (SDK), vous devez effectuer des actions sur l’objet HttpConfiguration.

Installer le SDK

Pour installer le Kit de développement logiciel (SDK), cliquez avec le bouton droit sur le projet de serveur dans Visual Studio, sélectionnez Gérer les packages NuGet, recherchez le package Microsoft.Azure.Mobile.Server, puis cliquez sur Installer.

Initialiser le projet de serveur

Un projet de serveur principal .NET est initialisé similaire à d’autres projets ASP.NET, notamment une classe de démarrage OWIN. Vérifiez que vous avez référencé le package NuGet Microsoft.Owin.Host.SystemWeb. Pour ajouter cette classe dans Visual Studio, cliquez avec le bouton droit sur votre projet de serveur, puis sélectionnez Ajouter>nouvel élément, puis classe De démarrage Web>Général>OWIN Startup. Une classe est générée avec l’attribut suivant :

[assembly: OwinStartup(typeof(YourServiceName.YourStartupClassName))]

Dans la méthode Configuration() de votre classe de démarrage OWIN, utilisez un objet HttpConfiguration pour configurer l’environnement Azure Mobile Apps. L’exemple suivant initialise le projet de serveur sans fonctionnalités ajoutées :

// in OWIN startup class
public void Configuration(IAppBuilder app)
{
    HttpConfiguration config = new HttpConfiguration();

    new MobileAppConfiguration()
        // no added features
        .ApplyTo(config);

    app.UseWebApi(config);
}

Pour activer des fonctionnalités individuelles, vous devez appeler des méthodes d’extension sur l’objet MobileAppConfiguration avant d’appeler ApplyTo. Par exemple, le code suivant ajoute les itinéraires par défaut à tous les contrôleurs d’API qui ont l’attribut [MobileAppController] lors de l’initialisation :

new MobileAppConfiguration()
    .MapApiControllers()
    .ApplyTo(config);

Le démarrage rapide du serveur à partir du portail Azure appelle UseDefaultConfiguration(). Cela équivaut à la configuration suivante :

    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);

Les méthodes d’extension utilisées sont les suivantes :

AddMobileAppHomeController() fournit la page d’accueil Par défaut d’Azure Mobile Apps.
MapApiControllers() fournit des fonctionnalités d’API personnalisées pour les contrôleurs WebAPI décorés avec l’attribut [MobileAppController].
AddTables() fournit un mappage des points de terminaison /tables aux contrôleurs de table.
AddTablesWithEntityFramework() est un raccourci pour mapper les points de terminaison /tables à l’aide de contrôleurs basés sur Entity Framework.
AddPushNotifications() fournit une méthode simple d’inscription d’appareils pour Notification Hubs.
MapLegacyCrossDomainController() fournit des en-têtes CORS standard pour le développement local.

Extensions du Kit de développement logiciel (SDK

Les packages d’extension NuGet suivants fournissent différentes fonctionnalités mobiles qui peuvent être utilisées par votre application. Vous activez les extensions pendant l’initialisation à l’aide de l’objet MobileAppConfiguration.

Microsoft.Azure.Mobile.Server.Quickstart prend en charge la configuration de base de Mobile Apps. Ajouté à la configuration en appelant la méthode d’extension UseDefaultConfiguration lors de l’initialisation. Cette extension inclut les extensions suivantes : Notifications, Authentification, Entité, Tables, Inter-domaines et packages Home. Ce package est utilisé par le guide de démarrage rapide des applications mobiles disponible sur le portail Azure.
Microsoft.Azure.Mobile.Server.Home Implémente par défaut la page indiquant que cette application mobile est opérationnelle pour la racine du site web. Ajoutez à la configuration en appelant la méthode d’extension AddMobileAppHomeController.
Microsoft.Azure.Mobile.Server.Tables inclut des classes permettant d’utiliser des données et de configurer le pipeline de données. Ajoutez à la configuration en appelant la méthode d’extension addTables .
Microsoft.Azure.Mobile.Server.Entity permet à Entity Framework d’accéder aux données dans la base de données SQL. Ajoutez à la configuration en appelant la méthode d’extension AddTablesWithEntityFramework.
Microsoft.Azure.Mobile.Server.Authentication Active l’authentification et configure le middleware OWIN utilisé pour valider les jetons. Ajoutez à la configuration en appelant les méthodes d'extension AddAppServiceAuthentication et IAppBuilder.UseAppServiceAuthentication.
Microsoft.Azure.Mobile.Server.Notifications Active les notifications Push et définit un point de terminaison d’inscription Push. Ajoutez à la configuration en appelant la méthode d’extension AddPushNotifications.
Microsoft.Azure.Mobile.Server.CrossDomain Crée un contrôleur qui sert des données aux anciens navigateurs web de votre application mobile. Ajoutez à la configuration en appelant la méthode d’extension MapLegacyCrossDomainController.
Microsoft.Azure.Mobile.Server.Login Fournit la méthode AppServiceLoginHandler.CreateToken(), qui est une méthode statique utilisée pendant les scénarios d’authentification personnalisés.

Guide pratique pour publier le projet de serveur

Cette section vous montre comment publier votre projet principal .NET à partir de Visual Studio. Vous pouvez également déployer votre projet back-end à l’aide de Git ou de l’une des autres méthodes disponibles.

Dans Visual Studio, régénérez le projet pour restaurer des packages NuGet.
Dans l’Explorateur de solutions, cliquez avec le bouton droit sur le projet, cliquez sur Publier. La première fois que vous publiez, vous devez définir un profil de publication. Lorsque vous avez déjà défini un profil, vous pouvez le sélectionner et cliquer sur Publier.
Si vous êtes invité à sélectionner une cible de publication, cliquez sur Microsoft Azure App Service>Prochaine, puis (si nécessaire) connexion avec vos informations d’identification Azure. Visual Studio télécharge et stocke en toute sécurité vos paramètres de publication directement à partir d’Azure.
Choisissez votre d’abonnement, sélectionnez Type de ressource dans Affichage, développez Application Mobile, puis cliquez sur le backend de l'application mobile, puis sur OK.
Vérifiez les informations du profil de publication, puis cliquez sur Publier.

Lorsque votre back-end Mobile App a été publié avec succès, vous voyez une page d’accueil indiquant la réussite.

Guide pratique pour définir un contrôleur de table

Définissez un contrôleur de table pour exposer une table SQL aux clients mobiles. La configuration d’un contrôleur de table nécessite trois étapes :

Créez une classe DTO (Data Transfer Object).
Configurez une référence de table dans la classe Mobile DbContext.
Créez un contrôleur de table.

Un objet DTO (Data Transfer Object) est un objet C# brut qui hérite de EntityData. Par exemple:

public class TodoItem : EntityData
{
    public string Text { get; set; }
    public bool Complete {get; set;}
}

Le DTO est utilisé pour définir la table dans la base de données SQL. Pour créer l’entrée de base de données, ajoutez une propriété DbSet<> au DbContext que vous utilisez. Dans le modèle de projet par défaut pour Azure Mobile Apps, dbContext est appelé 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()));
    }
}

Si le Kit de développement logiciel (SDK) Azure est installé, vous pouvez maintenant créer un contrôleur de table de modèles comme suit :

Cliquez avec le bouton droit sur le dossier Contrôleurs, puis sélectionnez Ajouter>contrôleur....
Sélectionnez l’option contrôleur de table Azure Mobile Apps, puis cliquez sur Ajouter.
Dans la boîte de dialogue Ajouter un contrôleur :
- Dans la liste déroulante du modèle de classe , sélectionnez votre nouveau DTO.
- Dans la liste déroulante DbContext, sélectionnez la classe DbContext du service mobile.
- Le nom du contrôleur est créé pour vous.
Cliquez sur Ajouter.

Le projet de serveur de démarrage rapide contient un exemple simple de TodoItemController.

Guide pratique pour ajuster la taille de pagination de la table

Par défaut, Azure Mobile Apps retourne 50 enregistrements par requête. La pagination garantit que le client ne lie pas son thread d’interface utilisateur ni le serveur pendant trop longtemps, ce qui garantit une bonne expérience utilisateur. Pour modifier la taille de pagination de la table, augmentez la « taille de requête autorisée » côté serveur et la taille de page côté client La taille de la page côté serveur « taille de requête autorisée » est ajustée à l’aide de l’attribut EnableQuery :

[EnableQuery(PageSize = 500)]

Vérifiez que PageSize est identique ou supérieur à la taille demandée par le client. Pour plus d’informations sur la modification de la taille de page du client, reportez-vous à la documentation HOWTO spécifique du client.

Guide pratique pour définir un contrôleur d’API personnalisé

Le contrôleur d’API personnalisé fournit les fonctionnalités les plus élémentaires à votre back-end d’application mobile en exposant un point de terminaison. Vous pouvez inscrire un contrôleur d’API spécifique à un mobile à l’aide de l’attribut [MobileAppController]. L'attribut MobileAppController enregistre le chemin, configure le sérialiseur JSON des applications mobiles et active la vérification de la version du client .

Dans Visual Studio, cliquez avec le bouton droit sur le dossier Contrôleurs, puis cliquez sur Ajouter>contrôleur, sélectionnez contrôleur d’API web 2 : vide, puis cliquez sur Ajouter.
Fournissez un nom de contrôleur , par exemple CustomController, puis cliquez sur Ajouter.
Dans le nouveau fichier de classe de contrôleur, ajoutez l’instruction using suivante :
```
 using Microsoft.Azure.Mobile.Server.Config;
```
Appliquez le [MobileAppController] attribut à la définition de classe du contrôleur d’API, comme dans l’exemple suivant :
```
 [MobileAppController]
 public class CustomController : ApiController
 {
       //...
 }
```
Dans le fichier App_Start/Startup.MobileApp.cs, ajoutez un appel à la méthode d’extension MapApiControllers, comme dans l’exemple suivant :
```
 new MobileAppConfiguration()
     .MapApiControllers()
     .ApplyTo(config);
```

Vous pouvez également utiliser la méthode d’extension UseDefaultConfiguration() au lieu de MapApiControllers(). Tout contrôleur qui n’a pas MobileAppControllerAttribute appliqué est toujours accessible par les clients, mais il peut ne pas être utilisé correctement par les clients à l’aide d’un KIT de développement logiciel (SDK) client Mobile App.

Guide pratique pour utiliser l’authentification

Azure Mobile Apps utilise l’authentification/l’autorisation App Service pour sécuriser votre back-end mobile. Cette section vous montre comment effectuer les tâches liées à l’authentification suivantes dans votre projet de serveur principal .NET :

Comment : ajouter l’authentification à un projet de serveur
Comment : utiliser l’authentification personnalisée pour votre application
Comment : récupérer des informations utilisateur authentifiées
Comment : restreindre l’accès aux données pour les utilisateurs autorisés

Guide pratique pour ajouter l’authentification à un projet de serveur

Vous pouvez ajouter l’authentification à votre projet de serveur en étendant l’objet MobileAppConfiguration et en configurant l’intergiciel OWIN. Lorsque vous installez le package de démarrage rapide Microsoft.Azure.Mobile.Server.Quickstart et appelez la méthode d’extension UseDefaultConfiguration, vous pouvez passer à l’étape 3.

Dans Visual Studio, installez le package Microsoft.Azure.Mobile.Server.Authentication.
Dans le fichier projet Startup.cs, ajoutez la ligne de code suivante au début de la méthode Configuration :
```
 app.UseAppServiceAuthentication(config);
```
Ce composant d’intergiciel OWIN valide les jetons émis par la passerelle App Service associée.
Ajoutez l’attribut [Authorize] à n’importe quel contrôleur ou méthode qui nécessite l’authentification.

Pour en savoir plus sur l’authentification des clients auprès de votre serveur principal Mobile Apps, consultez Ajouter une authentification à votre application.

Guide pratique pour utiliser l’authentification personnalisée pour votre application

Important

Pour activer l’authentification personnalisée, vous devez d’abord activer l’authentification App Service sans sélectionner de fournisseur pour votre App Service dans le portail Azure. Cela active la variable d’environnement WEBSITE_AUTH_SIGNING_KEY lors de l’hébergement.

Si vous ne souhaitez pas utiliser l’un des fournisseurs d’authentification/autorisation App Service, vous pouvez implémenter votre propre système de connexion. Installez le package microsoft.Azure.Mobile.Server.Login pour faciliter la génération de jetons d’authentification. Fournissez votre propre code pour valider les informations d’identification de l’utilisateur. Par exemple, vous pouvez vérifier les mots de passe salés et hachés dans une base de données. Dans l’exemple ci-dessous, la méthode isValidAssertion() (définie ailleurs) est responsable de ces vérifications.

L’authentification personnalisée est exposée en créant un ApiController et en exposant les actions register et login. Le client doit utiliser une interface utilisateur personnalisée pour collecter les informations de l’utilisateur. Les informations sont ensuite envoyées à l’API avec un appel HTTP POST standard. Une fois que le serveur valide l’assertion, un jeton est émis à l’aide de la méthode AppServiceLoginHandler.CreateToken(). Le ApiController ne doit pas utiliser l’attribut [MobileAppController].

Exemple d’action 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();
        }
    }

Dans l’exemple précédent, LoginResult et LoginResultUser sont des objets sérialisables exposant les propriétés requises. Le client s’attend à ce que les réponses de connexion soient retournées en tant qu’objets JSON du formulaire :

    {
        "authenticationToken": "<token>",
        "user": {
            "userId": "<userId>"
        }
    }

La méthode AppServiceLoginHandler.CreateToken() inclut un d’audience et un paramètre émetteur. Ces deux paramètres sont définis sur l’URL de la racine de votre application, à l’aide du schéma HTTPS. De même, vous devez définir secretKey comme valeur de la clé de signature de votre application. Ne distribuez pas la clé de signature dans un client, car elle peut être utilisée pour générer des clés et usurper l’identité des utilisateurs. Vous pouvez obtenir la clé de signature lors de l’hébergement dans App Service en référençant la variable d’environnement WEBSITE_AUTH_SIGNING_KEY. Si nécessaire dans un contexte de débogage local, suivez les instructions de la section Débogage local avec l’authentification section pour récupérer la clé et la stocker en tant que paramètre d’application.

Le jeton émis peut également inclure d’autres revendications et une date d’expiration. Au minimum, le jeton émis doit inclure une revendication de sujet (sub).

Vous pouvez prendre en charge la méthode client standard loginAsync() en surchargeant la route d’authentification. Si le client appelle client.loginAsync('custom'); pour se connecter, votre parcours doit être /.auth/login/custom. Vous pouvez définir l’itinéraire du contrôleur d’authentification personnalisé à l’aide de MapHttpRoute():

config.Routes.MapHttpRoute("custom", ".auth/login/custom", new { controller = "CustomAuth" });

Conseil / Astuce

L’utilisation de l’approche loginAsync() garantit que le jeton d’authentification est attaché à chaque appel ultérieur au service.

Guide pratique pour récupérer des informations utilisateur authentifiées

Lorsqu’un utilisateur est authentifié par App Service, vous pouvez accéder à l’ID d’utilisateur affecté et à d’autres informations dans votre code principal .NET. Les informations utilisateur peuvent être utilisées pour prendre des décisions d’autorisation dans le back-end. Le code suivant obtient l’ID utilisateur associé à une requête :

// Get the SID of the current user.
var claimsPrincipal = this.User as ClaimsPrincipal;
string sid = claimsPrincipal.FindFirst(ClaimTypes.NameIdentifier).Value;

Le SID est dérivé de l’ID utilisateur spécifique au fournisseur et est statique pour un utilisateur et un fournisseur de connexion donnés. Le SID est null pour les jetons d’authentification non valides.

App Service vous permet également de demander des revendications spécifiques à votre fournisseur de connexion. Chaque fournisseur d’identité peut fournir plus d’informations à l’aide du Kit de développement logiciel (SDK) du fournisseur d’identité. Par exemple, vous pouvez utiliser l’API Facebook Graph pour obtenir des informations sur vos amis. Vous pouvez spécifier des revendications demandées dans le panneau fournisseur dans le portail Azure. Certaines revendications nécessitent une configuration supplémentaire avec le fournisseur d’identité.

Le code suivant appelle la méthode d’extension GetAppServiceIdentityAsync pour obtenir les informations d’identification de connexion, notamment le jeton d’accès nécessaire pour effectuer des demandes sur l’API Facebook Graph :

// 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();
}

Ajoutez une instruction using pour System.Security.Principal afin de fournir la méthode d'extension GetAppServiceIdentityAsync.

Guide pratique pour restreindre l’accès aux données pour les utilisateurs autorisés

Dans la section précédente, nous avons montré comment récupérer l’ID d’utilisateur d’un utilisateur authentifié. Vous pouvez restreindre l’accès aux données et à d’autres ressources en fonction de cette valeur. Par exemple, l’ajout d’une colonne userId aux tables et le filtrage des résultats de la requête par l’ID utilisateur est un moyen simple de limiter les données retournées uniquement aux utilisateurs autorisés. Le code suivant retourne des lignes de données uniquement lorsque le SID correspond à la valeur de la colonne UserId de la table 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);

La méthode Query() retourne une IQueryable qui peut être manipulée par LINQ pour gérer le filtrage.

Guide pratique pour ajouter des notifications Push à un projet de serveur

Ajoutez des notifications Push à votre projet de serveur en étendant l’objet MobileAppConfiguration et en créant un client Notification Hubs.

Dans Visual Studio, cliquez avec le bouton droit sur le projet de serveur, puis cliquez sur Gérer les packages NuGet, recherchez Microsoft.Azure.Mobile.Server.Notifications, puis cliquez sur Installer.
Répétez cette étape pour installer le package Microsoft.Azure.NotificationHubs, qui inclut la bibliothèque cliente Notification Hubs.
Dans App_Start/Startup.MobileApp.cs, puis ajoutez un appel à la méthode d’extension AddPushNotifications() lors de l’initialisation :
```
 new MobileAppConfiguration()
     // other features...
     .AddPushNotifications()
     .ApplyTo(config);
```

Ajoutez le code suivant qui crée un client Notification Hubs :

 // 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);

Vous pouvez maintenant utiliser le client Notification Hubs pour envoyer des notifications Push à des appareils inscrits. Pour plus d’informations, consultez Ajouter des notifications Push à votre application. Pour en savoir plus sur Notification Hubs, consultez Vue d’ensemble de Notification Hubs.

Guide pratique pour activer l’envoi (push) ciblé à l’aide de balises

Notification Hubs vous permet d’envoyer des notifications ciblées à des inscriptions spécifiques à l’aide de balises. Plusieurs balises sont créées automatiquement :

L’ID d’installation identifie un appareil spécifique.
L’ID d’utilisateur basé sur le SID authentifié identifie un utilisateur spécifique.

L’ID d’installation est accessible à partir de la propriété installationId sur le MobileServiceClient. L’exemple suivant montre comment utiliser un ID d’installation pour ajouter une balise à une installation spécifique dans Notification Hubs :

hub.PatchInstallation("my-installation-id", new[]
{
    new PartialUpdateOperation
    {
        Operation = UpdateOperationType.Add,
        Path = "/tags",
        Value = "{my-tag}"
    }
});

Les balises fournies par le client pendant l’inscription de notification Push sont ignorées par le serveur principal lors de la création de l’installation. Pour permettre à un client d’ajouter des balises à l’installation, vous devez créer une API personnalisée qui ajoute des balises à l’aide du modèle précédent.

Consultez balises de notification Push ajoutées au client dans l’exemple de démarrage rapide App Service Mobile Apps pour obtenir un exemple.

Guide pratique pour envoyer des notifications Push à un utilisateur authentifié

Lorsqu’un utilisateur authentifié s’inscrit pour les notifications Push, une balise d’ID d’utilisateur est automatiquement ajoutée à l’inscription. À l’aide de cette balise, vous pouvez envoyer des notifications Push à tous les appareils inscrits par cette personne. Le code suivant obtient le SID de l’utilisateur effectuant la demande et envoie une notification push modèle à chaque enregistrement d’appareil pour cette personne.

// 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);

Lors de l’inscription pour les notifications Push à partir d’un client authentifié, assurez-vous que l’authentification est terminée avant d’essayer d’inscrire. Pour plus d’informations, consultez Push aux utilisateurs dans l’exemple de démarrage rapide App Service Mobile Apps pour le back-end .NET.

Guide pratique pour déboguer et dépanner le Kit de développement logiciel (SDK) .NET Server

Azure App Service fournit plusieurs techniques de débogage et de résolution des problèmes pour les applications ASP.NET :

Exploitation forestière

Vous pouvez écrire dans les journaux de diagnostic App Service à l’aide de la fonctionnalité de traçage standard d'ASP.NET. Avant de pouvoir écrire dans les journaux, vous devez activer les diagnostics dans le back-end de votre application mobile.

Pour activer les diagnostics et écrire dans les journaux de logs :

Suivez les étapes décrites dans Activer la journalisation des applications (Windows).
Ajoutez l’instruction using suivante dans votre fichier de code :
```
 using System.Web.Http.Tracing;
```
Créez un enregistreur de trace afin d'écrire depuis le back-end .NET dans les journaux de diagnostic, comme suit :
```
 ITraceWriter traceWriter = this.Configuration.Services.GetTraceWriter();
 traceWriter.Info("Hello, World");
```
Republiez votre projet de serveur et accédez au back-end Mobile App pour exécuter le chemin du code avec la journalisation.
Téléchargez et évaluez les fichiers de logs, comme décrit dans fichiers journaux d'accès.

Débogage local avec authentification

Vous pouvez exécuter votre application localement pour tester les modifications avant de les publier dans le cloud. Pour la plupart des back-ends Azure Mobile Apps, appuyez sur F5 dans Visual Studio. Toutefois, il existe des considérations supplémentaires lors de l’utilisation de l’authentification.

Vous devez disposer d’une application mobile basée sur le cloud avec l’authentification/autorisation App Service configurée, et votre client doit avoir le point de terminaison cloud spécifié comme autre hôte de connexion. Consultez la documentation de votre plateforme cliente pour connaître les étapes spécifiques requises.

Vérifiez que votre serveur principal mobile a Microsoft.Azure.Mobile.Server.Authentication installé. Ensuite, dans la classe de démarrage OWIN de votre application, ajoutez ce qui suit, une fois que MobileAppConfiguration a été appliqué à votre HttpConfiguration:

    app.UseAppServiceAuthentication(new AppServiceAuthenticationOptions()
    {
        SigningKey = ConfigurationManager.AppSettings["authSigningKey"],
        ValidAudiences = new[] { ConfigurationManager.AppSettings["authAudience"] },
        ValidIssuers = new[] { ConfigurationManager.AppSettings["authIssuer"] },
        TokenHandler = config.GetAppServiceTokenHandler()
    });

Dans l’exemple précédent, vous devez configurer les paramètres authAudience et authIssuer au sein de votre fichier Web.config pour que chacune soit l’URL de la racine de votre application, en utilisant le schéma HTTPS. De même, vous devez définir authSigningKey comme valeur de la clé de signature de votre application. Pour obtenir la clé de signature :

Accédez à votre application dans le portail Azure
Cliquez sur Outils, Kudu, Go.
Dans le site de gestion Kudu, cliquez sur Environnement.
Recherchez la valeur de WEBSITE_AUTH_SIGNING_KEY.

Utilisez la clé de signature pour le paramètre authSigningKey dans la configuration de votre application locale. Votre back-end mobile est maintenant équipé pour valider les jetons lors de l’exécution locale, que le client obtient le jeton à partir du point de terminaison cloud.

Partager via