Vue d’ensemble de Windows Push Notification Services (WNS)

Les services de notification Push Windows (WNS) permettent aux développeurs tiers d’envoyer des notifications toast, des tuiles, des badges et des notifications brutes à partir de leur propre service de cloud. Cela fournit un mécanisme permettant de fournir de nouvelles mises à jour à vos utilisateurs de manière efficace et fiable.

Fonctionnement

Le diagramme suivant montre le flux de données complet pour l’envoi d’une notification Push. Elle implique ces étapes :

1. Votre application demande un canal de notification Push à partir de WNS.
2. Windows demande à WNS de créer un canal de notification. Ce canal est retourné à l’appareil appelant sous la forme d’un URI (Uniform Resource Identifier).
3. L’URI du canal de notification est retourné par WNS à votre application.
4. Votre application envoie l’URI à votre propre service cloud. Vous stockez ensuite l’URI sur votre propre service cloud afin de pouvoir accéder à l’URI lorsque vous envoyez des notifications. L’URI est une interface entre votre propre application et votre propre service ; il vous incombe d’implémenter cette interface avec des normes web sécurisées et sécurisées.
5. Lorsque votre service cloud a une mise à jour à envoyer, il avertit WNS à l’aide de l’URI du canal. Pour ce faire, envoyez une requête HTTP POST, y compris la charge utile de notification, via SSL (Secure Sockets Layer). Cette étape nécessite l’authentification.
6. WNS reçoit la demande et achemine la notification vers l’appareil approprié.

Diagramme de flux de données de WNS

Inscription de votre application et réception des informations d’identification pour votre service cloud

Avant de pouvoir envoyer des notifications à l’aide de WNS, votre application doit être inscrite auprès du tableau de bord du Windows Store, comme décrit ici.

Demande d’un canal de notification

Lorsqu’une application capable de recevoir des notifications Push s’exécute, elle doit d’abord demander un canal de notification via CreatePushNotificationChannelForApplicationAsync. Pour obtenir une discussion complète et un exemple de code, consultez Comment demander, créer et enregistrer un canal de notification. Cette API retourne un URI de canal lié de manière unique à l’application appelante et à sa vignette, et via lequel tous les types de notification peuvent être envoyés.

Une fois que l’application a créé un URI de canal, elle l’envoie à son service cloud, ainsi que les métadonnées spécifiques à l’application qui doivent être associées à cet URI.

Remarques importantes

• Nous ne garantissons pas que l’URI du canal de notification d’une application reste toujours le même. Nous vous conseillons que l’application demande un nouveau canal chaque fois qu’il s’exécute et met à jour son service lorsque l’URI change. Le développeur ne doit jamais modifier l’URI du canal et doit le considérer comme une chaîne de zone noire. À ce stade, les URI de canal expirent après 30 jours. Si votre application Windows 10 renouvelle régulièrement son canal en arrière-plan, vous pouvez télécharger l’exemple de notifications Push et périodiques pour Windows 8.1 et réutiliser son code source et/ou le modèle qu’il illustre.
• L’interface entre le service cloud et l’application cliente est implémentée par vous, le développeur. Nous vous recommandons d’utiliser un processus d’authentification avec son propre service et de transmettre des données via un protocole sécurisé tel que HTTPS.
• Il est important que le service cloud garantit toujours que l’URI du canal utilise le domaine « notify.windows.com ». Le service ne doit jamais envoyer de notifications Push à un canal sur un autre domaine. Si le rappel de votre application est un jour compromis, un attaquant malveillant pourrait soumettre un URI de canal pour tromper WNS. Sans inspecter le domaine, votre service cloud peut potentiellement divulguer des informations à cet attaquant sans le savoir. Le sous-domaine de l’URI du canal est susceptible de changer et ne doit pas être pris en compte lors de la validation de l’URI du canal.
• Si votre service cloud tente de remettre une notification à un canal expiré, WNS retourne le code de réponse 410. En réponse à ce code, votre service ne doit plus tenter d’envoyer de notifications à cet URI.

Authentification de votre service cloud

Pour envoyer une notification, le service cloud doit être authentifié via WNS. La première étape de ce processus se produit lorsque vous inscrivez votre application auprès du tableau de bord du Microsoft Store. Pendant le processus d’inscription, votre application reçoit un identificateur de sécurité de package (SID) et une clé secrète. Ces informations sont utilisées par votre service cloud pour s’authentifier auprès de WNS.

Le schéma d’authentification WNS est implémenté à l’aide du profil d’informations d’identification du client à partir du protocole OAuth 2.0 . Le service cloud s’authentifie auprès de WNS en fournissant ses informations d’identification (SID de package et clé secrète). En retour, il reçoit un jeton d’accès. Ce jeton d’accès permet à un service cloud d’envoyer une notification. Le jeton est requis avec chaque demande de notification envoyée au service WNS.

À un niveau élevé, la chaîne d’informations est la suivante :

1. Le service cloud envoie ses informations d’identification à WNS via HTTPS en suivant le protocole OAuth 2.0. Cela authentifie le service avec WNS.
2. WNS retourne un jeton d’accès si l’authentification a réussi. Ce jeton d’accès est utilisé dans toutes les demandes de notification suivantes jusqu’à son expiration.

Dans l’authentification avec WNS, le service cloud envoie une requête HTTP sur SSL (Secure Sockets Layer). Les paramètres sont fournis au format « application/x-www-for-urlencoded ». Fournissez votre SID de package dans le champ « client_id » et votre clé secrète dans le champ « client_secret », comme indiqué dans l’exemple suivant. Pour plus d’informations sur la syntaxe, consultez la référence de demande de jeton d’accès .

 POST /accesstoken.srf HTTP/1.1
 Content-Type: application/x-www-form-urlencoded
 Host: https://login.live.com
 Content-Length: 211
 
 grant_type=client_credentials&client_id=ms-app%3a%2f%2fS-1-15-2-2972962901-2322836549-3722629029-1345238579-3987825745-2155616079-650196962&client_secret=Vex8L9WOFZuj95euaLrvSH7XyoDhLJc7&scope=notify.windows.com

Le service WNS authentifie le service cloud et, s’il réussit, envoie une réponse de « 200 OK ». Le jeton d’accès est retourné dans les paramètres inclus dans le corps de la réponse HTTP, à l’aide du type de média « application/json ». Une fois que votre service a reçu le jeton d’accès, vous êtes prêt à envoyer des notifications.

L’exemple suivant montre une réponse d’authentification réussie, y compris le jeton d’accès. Pour plus d’informations sur la syntaxe, consultez les en-têtes de demande et de réponse du service de notification Push.

 HTTP/1.1 200 OK   
 Cache-Control: no-store
 Content-Length: 422
 Content-Type: application/json
 
 {
     "access_token":"EgAcAQMAAAAALYAAY/c+Huwi3Fv4Ck10UrKNmtxRO6Njk2MgA=", 
     "token_type":"bearer"
 }

Remarques importantes

• Le protocole OAuth 2.0 pris en charge dans cette procédure suit la version préliminaire V16.
• La requête OAuth pour commentaires (RFC) utilise le terme « client » pour faire référence au service cloud.
• Il peut y avoir des modifications apportées à cette procédure lorsque le brouillon OAuth est finalisé.
• Le jeton d’accès peut être réutilisé pour plusieurs demandes de notification. Cela permet au service cloud de s’authentifier une seule fois pour envoyer de nombreuses notifications. Toutefois, lorsque le jeton d’accès expire, le service cloud doit s’authentifier à nouveau pour recevoir un nouveau jeton d’accès.

Envoi d’une notification

À l’aide de l’URI de canal, le service cloud peut envoyer une notification chaque fois qu’il a une mise à jour pour l’utilisateur.

Le jeton d’accès décrit ci-dessus peut être réutilisé pour plusieurs demandes de notification ; le serveur cloud n’est pas requis pour demander un nouveau jeton d’accès pour chaque notification. Si le jeton d’accès a expiré, la demande de notification retourne une erreur. Nous vous recommandons de ne pas essayer de renvoyer votre notification plusieurs fois si le jeton d’accès est rejeté. Si vous rencontrez cette erreur, vous devez demander un nouveau jeton d’accès et renvoyer la notification. Pour obtenir le code d'erreur exact, consultez les codes de réponse des notifications Push .

1. Le service cloud effectue une requête HTTP POST vers l’URI du canal. Cette demande doit être effectuée via SSL et contient les en-têtes nécessaires et la charge utile de notification. L’en-tête d’autorisation doit inclure le jeton d’accès acquis pour l’autorisation.

   Un exemple de requête est illustré ici. Pour plus d’informations sur la syntaxe, consultez codes de réponse pour les notifications push.

   Pour plus d’informations sur la composition de la charge utile de notification, consultez Démarrage rapide : Envoi d’une notification Push. La charge utile d’une notification Push de vignette, toast ou badge est fournie en tant que contenu XML qui respecte leur schéma de vignettes adaptatives respectivement ou schéma de vignettes héritées. La charge utile d’une notification brute n’a pas de structure spécifiée. Elle est strictement définie par l’application.

    POST https://cloud.notify.windows.com/?token=AQE%bU%2fSjZOCvRjjpILow%3d%3d HTTP/1.1
    Content-Type: text/xml
    X-WNS-Type: wns/tile
    Authorization: Bearer EgAcAQMAAAAALYAAY/c+Huwi3Fv4Ck10UrKNmtxRO6Njk2MgA=
    Host: cloud.notify.windows.com
    Content-Length: 24
   
    <body>
    ....
   

2. WNS répond pour indiquer que la notification a été reçue et sera remise à la prochaine occasion disponible. Toutefois, WNS ne fournit pas de confirmation de bout en bout indiquant que votre notification a été reçue par l’appareil ou l’application.

Ce diagramme illustre le flux de données :

diagramme

Remarques importantes

• WNS ne garantit pas la fiabilité ou la latence d’une notification.
• Les notifications ne doivent jamais inclure des données confidentielles, sensibles ou personnelles.
• Pour envoyer une notification, le service cloud doit d’abord s’authentifier auprès de WNS et recevoir un jeton d’accès.
• Un jeton d’accès permet uniquement à un service cloud d’envoyer des notifications à l’application unique pour laquelle le jeton a été créé. Un jeton d’accès ne peut pas être utilisé pour envoyer des notifications sur plusieurs applications. Par conséquent, si votre service cloud prend en charge plusieurs applications, il doit fournir le jeton d’accès correct pour l’application lors de l’envoi d’une notification à chaque URI de canal.
• Lorsque l’appareil est hors connexion, par défaut, WNS stocke un de chaque type de notification (vignette, badge, toast) pour chaque URI de canal et aucune notification brute.
• Dans les scénarios où le contenu de notification est personnalisé pour l’utilisateur, WNS recommande que le service cloud envoie immédiatement ces mises à jour lorsque celles-ci sont reçues. Par exemple, ce scénario inclut les mises à jour du flux de réseaux sociaux, les invitations de communication instantanée, les nouvelles notifications de messages ou les alertes. En guise d’alternative, vous pouvez avoir des scénarios dans lesquels la même mise à jour générique est fréquemment fournie à un grand sous-ensemble de vos utilisateurs ; par exemple, météo, stock et nouvelles mises à jour. Les instructions WNS spécifient que la fréquence de ces mises à jour doit être au maximum une toutes les 30 minutes. L’utilisateur final ou WNS peut déterminer des mises à jour de routine plus fréquentes pour être abusives.
• La plateforme de notification Windows gère une connexion de données périodique avec WNS pour maintenir le socket actif et sain. S’il n’existe aucune application demandant ou utilisant des canaux de notification, le socket ne sera pas créé.

Expiration des notifications de vignettes et de badges

Par défaut, les notifications de vignette et de badge expirent trois jours après le téléchargement. Lorsqu’une notification expire, le contenu est supprimé de la vignette ou de la file d’attente et n’est plus affiché à l’utilisateur. Il est recommandé de définir une expiration (à l’aide d’une heure qui est logique pour votre application) sur toutes les notifications de vignette et de badge afin que le contenu de votre vignette ne persiste pas plus longtemps qu’il n’est pertinent. Un délai d’expiration explicite est essentiel pour le contenu avec une durée de vie définie. Cela garantit également la suppression du contenu obsolète si votre service cloud cesse d’envoyer des notifications, ou si l’utilisateur se déconnecte du réseau pendant une période prolongée.

Votre service cloud peut définir une expiration pour chaque notification en définissant l’en-tête HTTP X-WNS-TTL pour spécifier l’heure (en secondes) pendant laquelle votre notification restera valide après son envoi. Pour plus d'informations, consultez les en-têtes de demande et de réponse du service de notification Push .

Par exemple, pendant la journée de négociation active d’un marché boursier, vous pouvez définir l’expiration d’une mise à jour du cours d’actions sur deux fois celle de votre intervalle d’envoi (par exemple, une heure après réception si vous envoyez des notifications toutes les demi-heures). Dans un autre exemple, une application d’actualités peut déterminer qu’un jour est une heure d’expiration appropriée pour une mise à jour quotidienne des vignettes d’actualités.

Notifications Push et économiseur de batterie

L’économiseur de batterie étend la durée de vie de la batterie en limitant l’activité en arrière-plan sur l’appareil. Windows 10 permet à l’utilisateur de définir l’économiseur de batterie pour l’activer automatiquement lorsque la batterie tombe sous un seuil spécifié. Lorsque l’économiseur de batterie est activé, la réception des notifications Push est désactivée pour économiser de l’énergie. Mais il y a quelques exceptions à cela. Les paramètres d’économiseur de batterie Windows 10 suivants (trouvés dans paramètres Windows) permettent à votre application de recevoir des notifications Push même lorsque l’économiseur de batterie est activé.

• Autoriser les notifications push de n’importe quelle application lors de l’économiseur de batterie: Ce paramètre permet à toutes les applications de recevoir des notifications push pendant que l’économiseur de batterie est activé. Notez que ce paramètre s’applique uniquement à Windows 10 pour les éditions de bureau (Famille, Professionnel, Entreprise et Éducation).
• Toujours autorisé : ce paramètre permet aux applications spécifiques de s’exécuter en arrière-plan pendant que l’économiseur de batterie est activé, y compris la réception de notifications Push. Cette liste est gérée manuellement par l’utilisateur.

Il n’existe aucun moyen de vérifier l’état de ces deux paramètres, mais vous pouvez vérifier l’état de l’économiseur de batterie. Dans Windows 10, utilisez la propriété EnergySaverStatus pour vérifier l’état de l’économiseur de batterie. Votre application peut également utiliser l’événement EnergySaverStatusChanged pour écouter les modifications apportées à l’économiseur de batterie.

Si votre application dépend fortement des notifications Push, nous vous recommandons d’informer les utilisateurs qu’ils ne reçoivent pas de notifications pendant que l’économiseur de batterie est activé et de faciliter l’ajustement des paramètres de l’économiseur de batterie. À l’aide du schéma d’URI des paramètres d’économiseur de batterie dans Windows, ms-settings:batterysaver-settingsvous pouvez fournir un lien pratique vers les paramètres Windows.

Voici un exemple de vérification de l’activation de l’économiseur de batterie dans Windows 10. Cet exemple avertit l’utilisateur et lance les paramètres de l’économiseur de batterie. Le dontAskAgainSetting permet à l’utilisateur de masquer le message s’il ne souhaite pas être averti à nouveau.

using System;
using Windows.UI.Xaml;
using Windows.UI.Xaml.Controls;
using Windows.UI.Xaml.Navigation;
using Windows.System;
using Windows.System.Power;
...
...
async public void CheckForEnergySaving()
{
   //Get reminder preference from LocalSettings
   bool dontAskAgain;
   var localSettings = Windows.Storage.ApplicationData.Current.LocalSettings;
   object dontAskSetting = localSettings.Values["dontAskAgainSetting"];
   if (dontAskSetting == null)
   {  // Setting does not exist
      dontAskAgain = false;
   }
   else
   {  // Retrieve setting value
      dontAskAgain = Convert.ToBoolean(dontAskSetting);
   }
   
   // Check if battery saver is on and that it's okay to raise dialog
   if ((PowerManager.EnergySaverStatus == EnergySaverStatus.On)
         && (dontAskAgain == false))
   {
      // Check dialog results
      ContentDialogResult dialogResult = await saveEnergyDialog.ShowAsync();
      if (dialogResult == ContentDialogResult.Primary)
      {
         // Launch battery saver settings (settings are available only when a battery is present)
         await Launcher.LaunchUriAsync(new Uri("ms-settings:batterysaver-settings"));
      }

      // Save reminder preference
      if (dontAskAgainBox.IsChecked == true)
      {  // Don't raise dialog again
         localSettings.Values["dontAskAgainSetting"] = "true";
      }
   }
}

#include <winrt/Windows.Foundation.h>
#include <winrt/Windows.Storage.h>
#include <winrt/Windows.System.h>
#include <winrt/Windows.System.Power.h>
#include <winrt/Windows.UI.Xaml.h>
#include <winrt/Windows.UI.Xaml.Controls.h>
#include <winrt/Windows.UI.Xaml.Navigation.h>
using namespace winrt;
using namespace winrt::Windows::Foundation;
using namespace winrt::Windows::Storage;
using namespace winrt::Windows::System;
using namespace winrt::Windows::System::Power;
using namespace winrt::Windows::UI::Xaml;
using namespace winrt::Windows::UI::Xaml::Controls;
using namespace winrt::Windows::UI::Xaml::Navigation;
...
winrt::fire_and_forget CheckForEnergySaving()
{
    // Get reminder preference from LocalSettings.
    bool dontAskAgain{ false };
    auto localSettings = ApplicationData::Current().LocalSettings();
    IInspectable dontAskSetting = localSettings.Values().Lookup(L"dontAskAgainSetting");
    if (!dontAskSetting)
    {
        // Setting doesn't exist.
        dontAskAgain = false;
    }
    else
    {
        // Retrieve setting value
        dontAskAgain = winrt::unbox_value<bool>(dontAskSetting);
    }

    // Check whether battery saver is on, and whether it's okay to raise dialog.
    if ((PowerManager::EnergySaverStatus() == EnergySaverStatus::On) && (!dontAskAgain))
    {
        // Check dialog results.
        ContentDialogResult dialogResult = co_await saveEnergyDialog().ShowAsync();
        if (dialogResult == ContentDialogResult::Primary)
        {
            // Launch battery saver settings
            // (settings are available only when a battery is present).
            co_await Launcher::LaunchUriAsync(Uri(L"ms-settings:batterysaver-settings"));
        }

        // Save reminder preference.
        if (dontAskAgainBox().IsChecked())
        {
            // Don't raise the dialog again.
            localSettings.Values().Insert(L"dontAskAgainSetting", winrt::box_value(true));
        }
    }
}

Il s'agit du code XAML pour le ContentDialog présenté dans cet exemple.

<ContentDialog x:Name="saveEnergyDialog"
               PrimaryButtonText="Open battery saver settings"
               SecondaryButtonText="Ignore"
               Title="Battery saver is on."> 
   <StackPanel>
      <TextBlock TextWrapping="WrapWholeWords">
         <LineBreak/><Run>Battery saver is on and you may 
          not receive push notifications.</Run><LineBreak/>
         <LineBreak/><Run>You can choose to allow this app to work normally
         while in battery saver, including receiving push notifications.</Run>
         <LineBreak/>
      </TextBlock>
      <CheckBox x:Name="dontAskAgainBox" Content="OK, got it."/>
   </StackPanel>
</ContentDialog>

Rubriques connexes

• Envoyer une notification de vignette locale
• démarrage rapide : envoi d’une notification Push
• Comment mettre à jour un badge via des notifications Push
• Comment demander, créer et enregistrer un canal de notification
• Comment intercepter les notifications pour l’exécution d’applications
• Comment s’authentifier auprès du service de notification Push Windows (WNS)
• En-têtes de demande et de réponse du service de notification Push
• Recommandations et liste de contrôle pour les notifications Push
• Notifications non traitées