Windows push notification platform

From Wikipedia, the free encyclopedia

Windows Push Notification Service

Windows Push Notification Service (commonly referred to as Windows Notification Service or WNS) is a notification service developed by Microsoft for all devices running Microsoft Windows platforms. It allows for developers to send push data («toast» and «tile» updates) to Windows and Universal Windows Platform applications which implement the feature.^[1] Designed as a successor to the Microsoft Push Notification Service, it was first supported on Windows 8 and subsequently on Windows Phone 8.1 upon its release.^[2]

The Windows Push Notification Service (WNS) was designed as a successor to the Microsoft Push Notification Service (MPNS), which was only supported natively on the Windows Phone 8 Operating System. Developers can still use the MPNS on apps that are installed on newer versions of Windows Mobile (Windows Phone 8 or Windows Phone 8.1), but only if the Windows application was already registered to use the MPNS and has been converted to a Microsoft Silverlight application and modified to re-target the new platform.^[3]

In 2015, Microsoft announced that the WNS would be expanded to utilize the Universal Windows Platform architecture, allowing for push data to be sent to Windows 10, Windows 10 Mobile, Xbox, as well as other supported platforms using universal API calls and POST requests.^[4]

During the 2015 Build keynote, Microsoft announced a Universal Windows Platform bridge that would allow Android and iOS software to be ported to Windows 10 Mobile and published to the Windows Store.^[5] In August 2015, A version of the Microsoft Android bridge toolset was reported to be leaked and available on the internet along with its documentation.^[6] The leaked toolset required developers to register and use the WNS to send notification data to ported applications, and would not allow for Google Cloud Messaging to be used instead. Microsoft later discontinued the Android bridge project in favor of continuing support for iOS application porting instead.^[7]

During the 2016 Build keynote, Microsoft announced an update to the WNS and the Windows 10 Operating System that will allow for Android and iOS devices to forward push notifications received to Windows 10 to be viewed and discarded.^[8]

The architecture of the Windows Push Notification Service is similar to that of its predecessor, in that it consists of servers and interfaces that generate, maintain, store, and authenticate unique identifiers (called Channel URI Identifiers) for all devices that register to use the service.^[2] When a device enrolls to receive data and notification information using the WNS, it first sends a device registration request to the WNS network. The WNS network acknowledges the request, and responds with the device’s unique Channel URI Identifier.^[9] Typically, the device will then send its identifier to a server owned by the developer so that it can be stored and used for sending notifications.^[1] When the app developer wishes to transmit a notification or other WNS data to the device, it will transmit a POST request to the WNS network.^[10] The network will acknowledge and authenticate the request. If the authentication succeeds, the data to be transmitted is enqueued and then sent to the device from the WNS network using the Channel URI Identifier.^{[citation needed]}

• Official website

Время на прочтение4 мин

Количество просмотров3.2K

Приветствую всех заинтересованных!

В современном мире все привыкли к быстрым коммуникациям через мессенджеры, многозадачности и возможности получать всплывающие на экран уведомления о событиях или сообщениях, не открывая при этом предварительно самого приложения. В Windows по аналогии с другими OS есть свой механизм для доставки уведомлений пользователю — Windows Push Notification Services (WNS). И при расследовании какого‑либо инцидента для форенсик специалиста могут быть полезны сведения из уведомлений Windows. Например представим ситуацию, что злоумышленник использовал мессенджер «WhatsApp», который использует механизм WNS для доставки уведомлений, но после использования удалил приложение и его данные. Как раз в таком случае и будут полезны сведения сохраняемые самой операционной системой и относящие к WNS.

Сведения из Windows Push Notification Services позволяют узнать следующее:

• На хосте запускалось то или иное приложение, т.к. каждое уведомление связано с конкретным приложением. Можно узнать дату установки этого приложения.

• Часть сообщений из мессенджеров, имена/никнеймы/почтовые адреса. Эта информация может содержаться в Payload уведомления.

• Действия, которые были выполнены некоторыми приложениями, т.к. ряд приложений могут выполнять действия в фоне, увеломления оповещают пользователя о результате/необходимости обратить внимание на что‑то. Это может содержаться в Payload уведомления.

Все уведомления в Windows делятся на три типа:

• Toast — всплывающее прямоугольное уведомление в правом нижнем углу экрана (в Windows 8.1 правый верхний угол).

Картинка с сайта: habr.com

• Tile — присутствует только в Windows 10/8.1 представляет собой «живую» плитку (анимации и обновляемая информация на плитке) в меню Пуск.

Картинка с сайта: habr.com

• Badge — цифра или символ рядом с иконкой приложения в Taskbar.

Картинка с сайта: habr.com

Сведения о них хранятся в файле %LOCALAPPDATA%\Microsoft\Windows\Notifications\wpndatabase.db, данный файл представляет собой SQLite базу данных. Внутри этой базы данных основной интерес будут представлять таблицы «Notification» и «NotificationHandler». Стоит отметить, что у уведомлений есть срок жизни и операционная система не сохраняет уведомления в базе данных насовсем. Например, если пользователь смахнул, нажал на уведомление или открыл приложение, которое отправило его, то оно будет удалено из базы. Однако, при удачном стечении обстоятельств недавно убранные системой записи из wpndatabase.db можно восстановить с помощью файла WAL (write‑ahead log), который находится в той же директории и имеет название wpndatabase.db‑wal. WAL представляет собой файл транзакций, все изменения в таблицах сначала будут отображены внутри этого файла. Прошлые изменения перестанут быть видны в файле WAL, когда в нём будет размещено более 1000 страниц (значение по умолчанию, прагма wal_autocheckpoint) (вся база SQLite состоит из страниц, размер страницы равен степени двойки, для wpndatabase.db размер страницы 4096 байт).

Картинка с сайта: habr.com

Вернёмся к таблицам внутри wpndatabase.db. В таблице «NotificationHandler» нас будет интересовать столбцы:

• PrimaryID — название приложения, которое может отправлять уведомления.

• RecordID — числовой идентификатор этого приложения.

• CreatedTime — соответствует дате установки приложения.

А в таблице «Notification» следующие:

• HandlerID — соответствует RecordID из «NotificationHandler».

• Type — тип уведомления.

• Payload — содержимое уведомления, обычно в XML формате.

• PayloadType — формат Payload.

• ArrivalTime — время поступления уведомления в формате Windows Filetime.

Рассмотрим инструменты для работы с этим видом доказательств. Из свободно распостраняемых утилит для форенсики wpndatabase.db хорошо подходит sql сценарий Notifications.sql. Он удобно группирует сведения из двух обозначенных нами таблиц.

Картинка с сайта: habr.com

Для восстановления уведомлений, которые убраны из основной базы, но которые могут оставаться в WAL подходит утилита walitean в сочетании с следующим sql запросом:

SELECT unknown0 AS Id, unknown1 AS HandlerId, unknown2 AS ActiveId, unknown3 AS Type, 
unknown4 AS Payload, unknown5 AS Tag, unknown6 AS 'Group', 
datetime((unknown7/10000000)-11644473600, 'unixepoch') AS ExpiryTime, 
datetime((unknown8/10000000)-11644473600, 'unixepoch') AS ArrivalTime, 
unknown9 AS DataVersion FROM IIBTBTTIIUTIU

Результат также получается достаточно удобный для анализа, за исключением того, что придётся вручную сопоставить HandlerID с именем приложения.

Картинка с сайта: habr.com

Также отдельно стоит отметить, что walitean написан на устаревшем Python 2, но тем не менее отлично отработал в Windows 11 на тестовом стенде. Подводя итог, артефакты из истории уведомлений могут быть хорошим вспомогательным источником, но учитывая небольшой срок жизни самих уведомлений и малый объём ротируемых данных в WAL, выжать из этого артефакта максимум информации не получится. Продолжение следует…

This service hosts Windows notification platform which provides support for local and push notifications. Supported notifications are tile, toast and raw.

The Windows Push Notifications User Service does not exist in:

• Windows 10 Home 1507
• Windows 10 Pro 1507
• Windows 10 Education 1507
• Windows 10 Enterprise 1507
• Windows 10 Home 1511
• Windows 10 Pro 1511
• Windows 10 Education 1511
• Windows 10 Enterprise 1511

Default Settings

Default Behavior

It is starting only if the user, an application or another service starts it in all editions of Windows 10 1607. This service is starting automatically when the operating system starts in all editions of Windows 10 1703, Windows 10 1709, Windows 10 1803, Windows 10 1809, Windows 10 1903, Windows 10 2004, Windows 10 20H2, Windows 10 21H1, Windows 10 21H2, Windows 10 22H2.

If Windows Push Notifications User Service fails to load or initialize, Windows 10 start up proceeds without warnings. However the error details are being logged.

Restore Default Startup Configuration of Windows Push Notifications User Service

1. Run the Command Prompt as an administrator.

2. Depending on the version of your operating system, copy the commands below, paste them into the command window and press ENTER.

For Windows 10 1607 Home, Windows 10 1607 Pro, Windows 10 1607 Education, Windows 10 1607 Enterprise:
sc config WpnUserService start= demand

For Windows 10 1703 Home, Windows 10 1703 Pro, Windows 10 1703 Education, Windows 10 1703 Enterprise, Windows 10 1709 Home, Windows 10 1709 Pro, Windows 10 1709 Education, Windows 10 1709 Enterprise, Windows 10 1803 Home, Windows 10 1803 Pro, Windows 10 1803 Education, Windows 10 1803 Enterprise, Windows 10 1809 Home, Windows 10 1809 Pro, Windows 10 1809 Education, Windows 10 1809 Enterprise, Windows 10 1903 Home, Windows 10 1903 Pro, Windows 10 1903 Education, Windows 10 1903 Enterprise, Windows 10 1909 Home, Windows 10 1909 Pro, Windows 10 1909 Education, Windows 10 1909 Enterprise, Windows 10 2004 Home, Windows 10 2004 Pro, Windows 10 2004 Education, Windows 10 2004 Enterprise, Windows 10 20H2 Home, Windows 10 20H2 Pro, Windows 10 20H2 Education, Windows 10 20H2 Enterprise, Windows 10 21H1 Home, Windows 10 21H1 Pro, Windows 10 21H1 Education, Windows 10 21H1 Enterprise, Windows 10 21H2 Home, Windows 10 21H2 Pro, Windows 10 21H2 Education, Windows 10 21H2 Enterprise, Windows 10 22H2 Home, Windows 10 22H2 Pro, Windows 10 22H2 Education, Windows 10 22H2 Enterprise:
sc config WpnUserService start= auto

sc start WpnUserService

3. Close the command window and restart the computer.

The WpnUserService service is using the WpnUserService.dll file that is located in the C:\Windows\System32 directory. If the file is removed or corrupted, read this article to restore its original version from Windows 10 installation media.

Вот мы и добрались до того места этой лекции, где мы можем отвлечься от исполняющихся приложений и посмотреть на больше интересных вещей, которые происходят в глубинах системы. Раньше, в «Периодических обновлениях», мы узнали, что самый короткий интервал, который может использовать этот метод, слишком велик по компьтерным меркам: 30 минут. Это долго и по многим человеческим стандартам, особенно тогда, когда пользователь по-настоящему желает знать, что происходит с любым источником информации, к которому подключено ваше приложение.

Для обновления плитки, установки индикатора уведомления или отправки всплывающего уведомления настолько быстро, насколько позволяет система, и для персонализации содержимого (как в случае с напоминаниями календаря или оповещениями об электронной почте), нужно быть немного настойчивее и использовать push-уведомления. Это уведомления, которые поступают в систему от агента, расположенного за её пределами, обычно – от сервиса, который отслеживает состояние каких-то других источников информации и обнаруживает условия, когда нужно отправить уведомление. Мы видели этот механизм в разделе «Четыре источника для обновлений и уведомлений» и на
рис.
4.14. Подводя итоги, можно сказать:

• При запуске, приложение запрашивает URI канала для каждой из своих динамических плиток и затем отправляет эти URI связанному с ним веб-сервису. Приложению следует делать это каждый раз при запуске, так как период истечения срока действия для WNS-канала – 30 дней . Каждый URI канала уникален для пользователя, плитки и устройства.
• Веб-сервис сохраняет URI канала и связывает его с пользователем для настройки содержимого уведомлений для него (как, опять же, происходит с оповещениями об электронной почте и о событиях календаря, уведомлениями об активности друзей и так далее).
• При необходимости веб-сервис отправляет обновление (полезные данные XML) в этот канал.
• WNS, в свою очередь, отправляет уведомление на устройство клиента, где приложение запросило URI канала. Это уведомление может обновлять плитки, индикаторы уведомлений, вызывать показ всплывающих уведомлений и обновлять данные на экране блокировки (при условии наличия соответствующих приложений экрана блокировки и фоновых задач).

Кроме того, возможно, и службе, и WNS, отправлять то, что называется необработанными уведомлениями (raw notification), которые могут включать в себя любую полезную нагрузку, которая вам нужна: надо лишь, чтобы что-то прослушивало их, так как Windows не будет знать, что делать с этими данными. Приложение переднего плана может прослушивать их посредством события PushNotificationChannel.onpushnotificationreceived; приложение экрана блокировки может сделать это с помощью фоновой задачи. В последнем случае необработанные уведомления обычно используются для доставки информации фоновой задаче и отправки других уведомлений в ответ, или для обновления данных приложения.

Прежде чем вы сможете сделать что-либо в приложении, однако, вам нужно следовать инструкциям, описанным в материале «Проверка подлинности с помощью службы push-уведомлений Windows (WNS)» (http://msdn.microsoft.com/library/windows/apps/hh465407.aspx) в Центре разработчиков Windows (это – часть целой серии материалов «Отправка push-уведомлений» (http://msdn.microsoft.com/library/windows/apps/hh465460.aspx)). Этот материал проведет вас по шагам, которые необходимо произвести в Информационной панели Магазина Windows (Windows Store Dashboard) для получения Идентификатора безопасности пакета (Package Security Identifie) (SID) и секретного ключа, которые ваш веб-сервис должен использовать для прохождения проверки подлинности при помощи WNS.

Это сделано, теперь давайте пройдёмся по каждому из этих шагов, используя Сценарии 1 – 3 того же самого примера «Push-уведомления и периодические уведомления, клиентская часть» (http://code.msdn.microsoft.com/windowsapps/Push-and-periodic-de225603), который мы использовали ранее при работе с периодическими обновлениями.

Примечание. Так как URI канала уникально для сочетания приложение+пользователь+устройство, использование push-уведомлений может создать серьезную нагрузку на ваш веб-сервис, который должен записывать и поддерживать канал для каждой отдельной плитки каждого пользовательского устройства и затем решать, когда и какие уведомления отправлять на каждый из каналов. Если ваше приложение станет популярным, это потребует масштабирования вашего сервиса для потенциально возможной ситуации, когда придётся управлять тысячами или даже миллионами URI каналов. По этой причине, серьезно подойдите к оценке того, подходят ли для вашего сценария периодические уведомления, особенно для обновлений, которые не относятся к конкретному пользователю, так как подобное гораздо легче выполнить на стороне сервиса.

Запрос и кэширование URI канала (приложение)

Запрос URI канала выполняется с помощью объекта Windows.Networking.PushNotifications.PushNotificationChannelManager. У этого управляющего объекта есть лишь два метода: createPushNotificationChannelForApplicationAsync и createPushNotificationChannelForSecondaryTileAsync. Первый связан с приложением и всплывающими уведомлениями. Второй предназначен для использования с дополнительными плитками и принимает аргумент tileId для идентификации конкретной плитки.

Результат обеих асинхронных операций – это объект PushNotificationChannel , который будет передан обработчику завершения, как показано в Сценарии 1 примера (начинается в js/scenario1.js, затем переходит в js/notifications.js):

  var channelOperation;
  // Канал для плитки приложения
  if (isPrimaryTile) {
  channelOperation = Windows.Networking.PushNotifications.PushNotificationChannelManager
  .createPushNotificationChannelForApplicationAsync();
  } else {
  // Канал для дополнительной плитки
  channelOperation = Windows.Networking.PushNotifications.PushNotificationChannelManager
  .createPushNotificationChannelForSecondaryTileAsync(itemId);
  }

  channelOperation.done(function (newChannel) {
  // Отправка канала веб-сервису
  };	/* обработчик ошибок */
  );

Объект PushNotificationChannel (newChannel в коде) это простой объект с несколькими членами, но они очень важны:

• expirationTime Свойство только для чтения, показывающее, когда истекает срок действия канала – уведомления, отправленные в этот канал после истечения срока, отклоняются. Приложение должно обновлять, при необходимости, свой канал, для того, чтобы предотвратить перебои в поступлении уведомлений.
• uri Только для чтения, содержит URI по которому веб-сервис приложения отправляет уведомления
• close Метод, который объявляет канал недействительным.
• pushnotificationreceived Событие, которое вызывается, когда уведомление поступает на клиентское устройство из канала уведомления. Оно вызывается только для приложения, которое находится на переднем плане.

Вашему приложению следует пройти через эти процедуры для того, чтобы получить необходимый URI канала, когда оно запускается или восстанавливается (в особенности, если для какого-то канала истекло время, показанное в expirationTime). Вряд ли приложение будет находиться очень долго в приостановленном режиме, но это возможно. Более того, если вы обеспокоены тем, что ваше приложение может не запускаться более чем 30 дней, вы можете реализовать фоновую задачу на основе триггера обслуживания (maintenance trigger) для этих целей. Смотрите «Задачи для триггеров обслуживания» дальше в этой лекции и Сценарий 2 примера.

Снова напоминаю, что у вас может быть больше, чем один URI канала, если вы так же используете push-уведомления для дополнительных плиток, как и для обычной плитки приложения. В этом случае вы будете работать с различными URI канала для каждой плитки.

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

Отправка URI вашему веб-сервису может быть выполнена с помощью простого вызова WinJS.xhr, как в примере (внутри channelOperation.done). Здесь мы так же видим проверки на то, не является ли URI тем же самым, что и раньше.

  
 channelOperation.done(function (newChannel) {
  // _urls[] это массив идентификаторов каналов для основной и дополнительной плиток
  var tileData = that._urls[itemId];

  // Отправка URI канала, если клиент не зафиксировал отправку того же самого
  // uri на сервер
  if (tileData && newChannel.uri === tileData.channelUri) {
  // Сохраняет URI в локальных данных приложения
  that._updateUrl(url, newChannel.uri, itemId, isPrimaryTile);
  completed(newChannel);
  } else { WinJS.xhr({
  type: "POST",
  url: url,
  headers: { "Content-Type": "application/x-www-form-urlencoded" }, data: "channelUri=" + encodeURIComponent(newChannel.uri) +
  "&itemId=" + encodeURIComponent(itemId)
  }).done(function (request) {

  // Обновление данных на клиенте если отправка URI канала прошла успешно.
  // Если это не удалось, вы можете решить настроить другую фоновую задачу, попытаться снова
  // и так далее. (Если операция выдаст ошибку, будет выдано исключение, тогда операция завершится
  // в обработчике ошибки.)
  that._updateUrl(url, newChannel.uri, itemId, isPrimaryTile);
  completed(newChannel);
  }, failed);
  }
  }, failed);

Управление URI каналов (Сервис)

Если вы использовали код из предыдущего раздела, ваш веб-сервис, который генерирует push-уведомления, получит запрос HTTP POST с уникальным URI канала для каждой плитки. Это не единственный способ передачи URI канала, конечно. На самом деле, так как URI канала могут быть использованы для передачи персональной информации через уведомления, его, в идеале, перед отправкой на сервер, следует зашифровать с помощью закрытого ключа. В противном случае кто-нибудь может перехватить этот URI и использовать его для перенаправления уведомлений, относящихся к конкретному пользователю.

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

Как только сервис получит URI канала вместе с любыми данными для идентификации пользователя и цели использования канала, он должен безопасно сохранить эту информацю в каком-нибудь постоянном хранилище, таком, как база данных SQL Server (для сервиса ASP.NET) или MySQL (для PHP-сервиса).

Так же важно, чтобы сервис удалял устаревшие URI каналов. Если он получает новый URI для того же пользователя и для той же цели, ему следует заменить старый на новый. Так же ему следует удалить из хранилища любые URI, если он получает в ответе от WNS ошибки HTTP 404 или 410, что указывает на устаревший канал.

Простую страницу сервиса ASP.NET, которая получает сообщение от Сценария 1 примера «Push-уведомления и периодические уведомления, клиентская часть» (http://code.msdn.microsoft.com/windowsapps/Push-and-periodic-de225603) можно найти в проекте веб-сайта HelloTiles в дополнительных материалах к лекции, в частности, это receiveuri.aspx. Для того, чтобы запустить этот сервис, убедитесь в том, что ваш локальный хост соответствующим образом настроен, как описано выше в разделе «Использование локального хоста». Так же вам может понадобиться установить ASP.NET на ваш локальный хост. Простой способ это сделать – загрузить пример «Фоновая передача данных» ( http://code.msdn.microsoft.com/windowsapps/Background-Transfer-Sample-d7833f61), перейти в его папку Server и затем, из командной строки администратора, выполнить команду powershell -ExecutionPolicy unrestrictedfile serversetup.ps1. Если затем вы запустите сайт в Visual Studio Express 2012 для Web, как мы делали раньше, у вас должен быть порт локального хоста для сервиса (например, http://localhost:52568/HelloTiles/receiveuri.aspx).

Затем вы можете установить точку останова в коде сервиса, вставить сервисный URI в Сценарий 1 примера «Push-уведомления и периодические уведомления, клиентская часть» и нажать его кнопку Reopen Channel And Send To Server (Повторно открыть канал и отправить на сервер). При этом должна сработать точка останова в сервисе, что позволить вам пошагово исполнить код, который обрабатывает запрос. Здесь вы можете обнаружить, что запрос содержит значения channelUri и itemId (наряду с LOGON_USER), которые могут быть сохранены для отправки уведомлений WNS, когда это будет нужно. Что-то похожее, конечно, можно написать на других серверных языках, хорошее место, где можно найти инструменты, которые помогут в написании кода сервисов, является Windows Azure Toolkit ( http://watwindows8.codeplex.com/).

Отправка обновлений и оповещений (Сервис)

Прежде чем сервис сможет отправлять обновления, он должен пройти проверку подлинности с помощью WINS, отправляя ему Идентификатор безопасности пакета (SID) и секретный ключ, полученные в Магазине Windows. Это можно сделать с помощью отправки WNS запроса XmlHttpRequest (через HTTPS), что может выглядеть примерно так:

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-13452385
  79-3987825745-2155616079-650196962&client_secret=Vex8L9WOFZuj95euaLrvSH7XyoDhLJc7&scope=notify.windows.com

Здесь вы должны убедиться, что значения client_id и client_secret соответствуют SID пакета и секретному ключу. Если проверка подлинности прошла успешно, вы получите ответ 200 OK с маркером доступа (access token), который понадобится вам для отправки уведомлений:

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

Код, который выполняет эти шаги для сервиса, написанного на C#, можно найти в материале «Проверка подлинности с помощью службы push-уведомлений Windows» (http://msdn.microsoft.com/library/windows/apps/hh465407.aspx), где ваш сервис будет использовать метод GetAccessToken, показанный здесь для получения объекта OAuthToken с информацией из ответа. Сервисы, написанные на других языках, очевидно, нуждаются в использовании подходящих средств для отправки запроса и получения ответа.

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

Для обновлений плиток и индикаторов события, для всплывающих уведомлений, отправка уведомления подразумевает создание полезных данных XML, как и для любых других обновлений или уведомлений, и затем отправка их WNS с ранее полученным маркером доступа. Единственная настоящая разница между этими запросами, помимо различного XML – это значение X-WNS-Type в заголовке запроса: wns/badge, wns/tile, wns/toast, или wns/raw (смотрите следующий раздел). Остальной код у них один и тот же.

Общий код для C#-сервисов можно найти в материалах «Краткое руководство: отправка push-уведомления» (http://msdn.microsoft.com/library/windows/apps/xaml/hh868252.aspx) и «Краткое руководство: отправка всплывающих push-уведомлений» (http://msdn.microsoft.com/library/windows/apps/xaml/hh868255.aspx). Я включил версию с обновлением индикатора событий в sendBadgeToWNS.aspx в сайт Hello Tiles, который находится в дополнительных материалах к этой лекции, там SID и секретный ключ – те, что я получил для примера «Push-уведомления и периодические уведомления, клиентская часть» (Вам может понадобиться создать новые для себя). Для того, чтобы всё это протестировать, запустим веб-сайт Hello Tiles в Visual Studio Express 2012 для Web и установим точку останова в начале sendBadgeToWNS.aspx. Предполагая, что вы запустили Сценарий 1 примера «Push-уведомления и периодические уведомления, клиентская часть» в Visual Studio Express 2012 для Windows 8 для отправки URI канала receiveuri.aspx, в проекте веб-сайта должен быть файл, который называется channeluri_aspx.txt, он содержит отправленные данные.

Теперь переключимся на Сценарий 3 примера и нажмём кнопку для того, чтобы начать прослушивание события pushnotificationreceived. В js/scenario3.js этого примера, установим точку останова в функции pushNotificationReceivedHandler. Когда всё готово, откроем браузер и введем адрес sendBadgeToWNS.aspx на локальном хосте: http://localhost:52568/HelloTiles/sendBadgeToWNS.aspx,например. Точка останова должна сработать в Visual Studio Express 2012 для Web, где вы можете пошагово исполнить код страницы и увидеть, что она загружает URI канала из channeluri_aspx.txt, по которому она затем отправляет обновление индикатора уведомления. Когда это происходит, должна сработать точку останова в приложении Push notifications, где вы так же можете пошагово исполнить код. Обратите внимание на то, что когда вы достигаете строки e.cancel=true, пропустите её, щелкните правой кнопкой мыши ниже её и выберите Задать следующий оператор (Set Next Statement). Это позволит Windows обработать уведомление и обновить индикатор событий для приложения-примера, который должен выглядеть сейчас примерно так, с индикатором * в нижнем правом углу:

Снова отмечу, что если вы получили в ответ от WNS сообщение об ошибке, это означает, что URI канала больше недействителен и вам следует удалить его из списка. Так же хорошо будет, чтобы ваше приложение оповещало сервис, когда ему не нужны обновления по конкретному каналу (нет смысла оплачивать непродуктивное использование полосы пропускания). И если WNS возвращает ошибку, не отправляйте обновление снова, если только это не имеет смысл для вашего сценария.

Ошибки 404 или 410, кстати, отличаются от невозможности доставить уведомление по причине того, что клиент не подключен к сети. В подобном случае WNS будет кэшировать уведомления для плитки, индикатора событий или необработанные уведомления до тех пор, пока клиент не подключится к сети. Другими словами, это не то, о чём должен беспокоиться сервис. Отправляйте уведомления как всегда, и позвольте WNS заниматься деталями их доставки.