Partager via

Vue d’ensemble des services de notifications Push Windows (WNS)

  • Article

Les Services de notifications Push Windows (WNS) permettent aux développeurs tiers d’envoyer des mises à jour brutes ainsi que des mises à jour par toast, vignette et badge à partir de leur propre service cloud. Il en résulte un mécanisme fiable et optimal de remise des nouvelles mises à jour aux utilisateurs.

Fonctionnement

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

  1. Votre application demande un canal de notification Push auprès des services WNS.
  2. Windows demande aux services 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 les services WNS à votre application.
  4. Votre application envoie l’URI à votre propre service cloud. Vous stockez ensuite l’URI dans votre propre service cloud afin de pouvoir y accéder lorsque vous envoyez des notifications. L’URI est une interface entre votre application et votre service. Il vous incombe d’implémenter cette interface avec des normes Web sécurisées.
  5. Lorsque votre service cloud a une mise à jour à envoyer, il en informe les services WNS à l’aide de l’URI du canal. Pour ce faire, il émet une requête HTTP POST, incluant la charge utile de notification, via SSL (Secure Sockets Layer). Cette étape nécessite une authentification.
  6. Les services WNS reçoivent la requête et acheminent la notification vers l’appareil approprié.

Diagramme de flux de données wns pour la notification Push

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

Pour que vous puissiez envoyer des notifications à l’aide des services WNS, vous devez avoir inscrit votre application auprès du Tableau de bord du Store comme décrit ici.

Demande d’un canal de notification

Lorsqu’une application capable de recevoir des notifications Push est en cours d’exécution, elle doit d’abord demander un canal de notification par le biais de CreatePushNotificationChannelForApplicationAsync. Pour obtenir une description 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 notifications 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 propres à l’application qui doivent être associées à cet URI.

Remarques importantes

  • Nous ne certifions pas que l’URI du canal de notification d’une application reste toujours le même. Nous recommandons que l’application demande un nouveau canal chaque fois qu’elle 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 type boîte noire. Pour le moment, 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 les exemples de notifications Push et périodiques pour Windows 8.1 et réutiliser leur code source et/ou le modèle qu’ils illustrent.
  • C’est vous, le développeur, qui implémentez l’interface entre le service cloud et l’application cliente. Nous conseillons de soumettre l’application à un processus d’authentification avec son propre service et de transmettre des données via un protocole sécurisé, par exemple HTTPS.
  • Il est important que le service cloud assure 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 compromis, un attaquant malveillant peut soumettre un URI de canal pour usurper l’identité des services WNS. Sans une inspection du domaine, votre service cloud peut divulguer des informations à cette personne malveillante sans le savoir. Le sous-domaine de l’URI du canal est susceptible d’être modifié 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é, les services WNS retournent le code de réponse 410. En réponse à ce code, votre service ne doit plus tenter d’envoyer des notifications à cet URI.

Authentification de votre service cloud

Pour envoyer une notification, le service cloud doit être authentifié via les services WNS. La première étape de ce processus a lieu 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 l’authentification auprès des services WNS.

Le schéma d’authentification des services 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 des services 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 aux services WNS.

Globalement, la chaîne d’informations est la suivante :

  1. Le service cloud envoie ses informations d’identification aux services WNS via HTTPS en suivant le protocole OAuth 2.0. Le service est alors authentifié auprès des services WNS.
  2. Les services WNS retournent un jeton d’accès si l’authentification a réussi. Ce jeton d’accès est utilisé dans toutes les demandes de notification ultérieures jusqu’à son expiration.

Diagramme wns pour l’authentification du service cloud

Dans l’authentification auprès des services WNS, le service cloud soumet une requête HTTP sur SSL. Les paramètres sont fournis au format « application/x-www-for-urlencoded ». Indiquez votre SID de package dans le champ « client_id » et votre clé secrète dans le champ « client_secret », comme illustré dans l’exemple suivant. Pour plus d’informations sur la syntaxe, consultez la référence sur les demandes de jeton d’accès.

Remarque

Il s’agit juste d’un exemple, et non du code à copier-coller que vous pouvez utiliser dans votre propre code. 

 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

Les services WNS authentifient le service cloud et, en cas de réussite, envoient la réponse « 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 illustre une réponse d’authentification réussie, incluant le jeton d’accès. Pour plus d’informations sur la syntaxe, consultez En-têtes de demande et de réponse des services de notifications 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.
  • Le document OAuth RFC (Request For Comments) utilise le terme « client » pour désigner le service cloud.
  • Des modifications peuvent être 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. Le service cloud peut ainsi 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 en recevoir un nouveau.

Envoi d’une notification

À l’aide de l’URI du canal, le service cloud peut envoyer une notification chaque fois qu’il dispose d’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 tenu de 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 aux notifications Push.

  1. Le service cloud effectue une requête HTTP POST auprès de l’URI du canal. Cette requête 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 les codes de réponse aux 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 par vignette, toast ou badge est fournie en tant que contenu XML qui respecte son schéma de vignettes adaptatives ou son schéma de vignettes héritées défini respectif. 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. Les services WNS répondent pour indiquer que la notification a été reçue et qu’elle sera remise à la prochaine opportunité disponible. Toutefois, les services WNS ne fournissent 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 wns pour l’envoi d’une notification

Remarques importantes

  • Les services WNS n’assurent ni la fiabilité ni la latence d’une notification.
  • Les notifications ne doivent jamais inclure de données confidentielles, sensibles ou personnelles.
  • Pour envoyer une notification, le service cloud doit d’abord s’authentifier auprès des services 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 dans 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 (push) d’une notification à chaque URI de canal.
  • Lorsque l’appareil est hors connexion, par défaut, les services WNS stockent une notification de chaque type (vignette, badge, toast) pour chaque URI de canal et aucune notification brute.
  • Dans les scénarios où le contenu de la notification est personnalisé pour l’utilisateur, les services WNS recommandent 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 de flux de réseaux sociaux, les invitations par communication instantanée, les notifications de nouveaux 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 large sous-ensemble de vos utilisateurs, par exemple, mises à jour de la météo, du stock et des actualités. Les instructions des services WNS spécifient que la fréquence de ces mises à jour doit être au maximum d’une toutes les 30 minutes. L’utilisateur final ou les services WNS peuvent estimer que des mises à jour de routine plus fréquentes sont abusives.
  • La plateforme de notification Windows gère une connexion de données périodique avec les services WNS pour que le socket reste actif et intègre. Si aucune application ne demande ou n’utilise de canaux de notification, le socket n’est pas créé.

Expiration des notifications par vignette et par badge

Par défaut, les notifications par vignette et par badge expirent trois jours après leur téléchargement. Lorsqu’une notification expire, son 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 (en utilisant une heure logique pour votre application) dans toutes les notifications par vignette et par badge afin que le contenu de votre vignette ne persiste pas plus longtemps que nécessaire. Une heure d’expiration explicite est essentielle pour les contenus avec une durée de vie définie. Cela garantit également la suppression de 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 la durée (en secondes) durant laquelle votre notification restera valide après son envoi. Pour plus d’informations, consultez En-têtes des demandes et des réponses des services de notifications Push.

Par exemple, pendant une 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). 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 d’une vignette d’actualités.

Notifications Push et économiseur de batterie

L’économiseur de batterie prolonge l’autonomie 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 qu’il s’active automatiquement lorsque le niveau de batterie tombe au-dessous d’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. Cependant il y a deux exceptions à ceci. Les paramètres suivants de l’économiseur de batterie Windows 10 (trouvés dans l’application Paramètres) permettent à votre application de recevoir des notifications Push même lorsque l’économiseur de batterie est activé.

  • Autoriser les notifications Push de toute application lorsque l’économiseur de batterie est activé : 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 éditions de bureau (Famille, Professionnel, Entreprise et Éducation).
  • Toujours autorisé : ce paramètre permet à des 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.

Aucune méthode ne permet 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 détecter les changements d’état de l’économiseur de batterie.

Si votre application dépend fortement des notifications Push, nous vous recommandons d’informer les utilisateurs qu’ils ne peuvent pas recevoir 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 de l’économiseur de batterie dans Windows 10, ms-settings:batterysaver-settings, vous pouvez fournir un lien pratique vers l’application Paramètres.

Conseil

Lorsque vous informez l’utilisateur des paramètres de l’économiseur de batterie, nous vous recommandons de proposer une option permettant de ne plus afficher le message à l’avenir. Par exemple, la case à cocher dontAskMeAgainBox dans l’exemple suivant conserve la préférence de l’utilisateur dans LocalSettings.

Voici un exemple illustrant comment vérifier si l’économiseur de batterie est activé dans Windows 10. Cet exemple informe l’utilisateur et lance l’application Paramètres sur les paramètres de l’économiseur de batterie. dontAskAgainSetting permet à l’utilisateur de supprimer le message s’il ne souhaite pas être informé de 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));
        }
    }
}

Voici le code XAML pour l’élément 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>