Статьи

Анатомия Push-уведомления

Декабрь 19, 2018

Я едва могу стоять,  не  зная, как что-то работает под капотом. Чаще всего я предпочитаю иметь практические знания о системе, а не об удобстве или функциях самой системы. Вот почему я преследовал степени в области компьютерной электроники и вычислительной техники в первую очередь. Я не так много знаю о всех модных вещах, которые инженеры вкладывают в процессоры и основные системные платы в наши дни, но я рад, что, по крайней мере, имею общее представление о шине управления, часах машины, MOSFET, программа сборки и программные абстракции более высокого уровня. Но я отвлекся …

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

Я должен сказать, что очень рад удобству абстракций мобильных служб Windows Azure (WAMS) в этом процессе, но я не хочу использовать его вслепую, не понимая, что он делает изнутри. Я собираюсь начать с обзора процесса и игроков в типичном push-уведомлении. Вы можете найти эту диаграмму и обзор процесса  здесь .

Зеленый — это  ты,  а синий — это  Microsoft.  Вы пишете приложение и несете ответственность за облачный сервис для связи с WNS.

В моей типичной попытке сделать сложный звук проще, я собираюсь провести вас через этот процесс.

  • [Шаги 1-3] Ваши приложения запрашивают у Windows канал.

    Вы запрашиваете у Windows канал, Windows запрашивает WNS (это происходит прозрачно для вас), а затем Windows дает вам канал. Этот канал просто строка. Вот пример URI с эллипсом, поскольку он на самом деле намного длиннее.

    https://bn1.notify.windows.com/?token=AgYAAABrcyAqFeh…wfOG5%2bD4TCeHU%3d

    Кстати, канал, который предоставляет вам Windows, также включает время истечения, которое может быть полезным.

  • [Шаг 4] Ваше приложение отправляет этот URI в ваш облачный сервис

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

  • [Шаг 5] Ваш облачный сервис запрашивает у WNS (сервер Microsoft) токен доступа, а затем запускает push

    Вот где происходит большая часть «магии». Ваш сервис выполняет два HTTP-вызова. Первый получает токен доступа (который вы, вероятно, захотите кэшировать), а второй (и последующие) инициирует отправку в ваше приложение. WNS знает, где находится ваше приложение, благодаря URI, который вы отправили.

    Вот примеры этих двух необработанных HTTP-сообщений …

    Первое сообщение

    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

    Это просто простой POST для login.live.com/accesstoken.srf. На самом деле client_id — это Идентификатор безопасности пакета (SID), который вы получаете с панели инструментов разработчика по адресу  http://dev.windows.com , а theclient_secret — это секрет клиента, который вы найдете в том же месте.

    Ответ на успешный запрос токена доступа похож на…

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

    При этом у вашего сервиса есть все, что нужно для отправки уведомлений в приложение.

    Второе сообщение

    У вашей службы есть токен доступа, и это все, что нужно для отправки запросов на передачу WNS в ваше приложение.

    Вот push-сообщение, которое меняет текст на вашей плитке …

    POST https://bn1.notify.windows.com/?token=AgYAAABrcyAqFeh...wfOG5%2bD4TCeHU%3d HTTP/1.1 
Content-Type: text/xml 
X-WNS-Type: wns/tile 
Authorization: Bearer EgAcAQMAAAAALYAAY/c+Huwi3Fv4Ck10UrKNmtxRO6Njk2MgA= 
Host: bn1.notify.windows.com 
Content-Length: 32 

<tile><visual><binding template="TileSquareText03"><text id="1">Message sent from push</text></binding></visual></tile>

    Обратите внимание на несколько вещей об этом сообщении …

    • Так же, как и запрос на токен доступа, это защищенный пост на https
    • Сообщение отправляется на URI канала
    • Вы можете найти действительные значения для заголовков Content-Type и X-WNS-Type  здесь
    • В заголовке авторизации всегда есть это слово Bearer, пробел, а затем токен доступа, полученный при первом вызове.
  • [Шаг 6] WNS отправляет уведомление в ваше приложение

    Этот шаг полностью выполняется в WNS и Windows, и вам не нужно ничего делать, кроме проверки того, что процесс работает.

И там у вас есть это. Вы можете найти множество услуг, которые обернут вам этот процесс и облегчат его, но теперь вы знаете, что происходит под капотом. Это не совсем то, что вы хотите попытаться объяснить своей маме, но это не совсем квантовая физика.

39
Share: