Confirmed users
1,022
edits
CloudServices/Notifications/Push: Difference between revisions
Jump to navigation
Jump to search
no edit summary
(→Push) |
No edit summary |
||
| Line 70: | Line 70: | ||
In addition, the framework will have to be able to support multiple output formats, including potential candidates like Jabber, Server Sent Events, etc. | In addition, the framework will have to be able to support multiple output formats, including potential candidates like Jabber, Server Sent Events, etc. | ||
= Push v. 0.5 Technical Overview = | |||
=== Definitions: === | |||
Client – A third party requesting the ability to send or receive notifications from a User via the User Agent. | |||
Distributor – A centralized hub which coordinates communication between the Clients and the User Agent | |||
User – The final consumer of push notification (generally presumed human) | |||
User Agent – The application acting on the User's behalf (generally presumed to be the browser) | |||
== Overview: == | |||
Push allows for small, semi-anonymous messages between a Client and a User Agent via a Distributor. The User Agent can be one or more devices, allowing the push notification to reach the User Agent where-ever or whenever they connect to the web. The notification content is secured from tampering and unauthorized viewing by encryption with keys provided by the User Agent to the Client. | |||
Clients receive a token representing a party that wishes to be notified of an event. When an event of interest occurs, the Client notifies the Distributor, which then passes the encrypted push notification to the User Agent for processing. | |||
== Components: == | |||
=== User Agent Configuration: === | |||
The first requirement of the system is that the User Agent register with the Distributor. This may be accomplished in any suitable manner, however once the User has properly authenticated against the Distributor, the User Agent makes a <tt>new_subscription</tt> request. This call will create a new subscription with the Distributor system (or return the subscription information for a previously created session for the user). | |||
The returned information will contain the subscription ID, which will allow the User Agent to connect to the Distributor for Notifications. (The method of distribution is dependent on the method used to connect, ex. SSE would use “http://$host/feed/$ID”, direct AMQP would use the ID as the Queue Name, etc.) | |||
Once the association is made to the User Agent, the Distributor can begin sending any new or previously unread messages. | |||
=== Client Javascript: === | |||
See (lib/main.js for most code related to the client) | |||
The User Agent contains an injected element called <tt>navigator.pushNotifications</tt> . This currently has a single method exposed to Clients <tt>requestPermissions(''params'', ''callback'')</tt>. The “params” argument contains server provided elements such as the application name (? Is this an echoed element that needs filtering/validation ?) & the account id ('account'). The publishing site and port is recorded by the plugin and stored as the 'host'. The <tt>navigator</tt> element is either browser native or injected from the notifications plug in. | |||
Once auth has completed, the server args are passed to the Client element for processing. | |||
=== Server Distribution: === | |||
A server wishing to notify a client of a new notification has several methods available to do so, however for this discussion we'll focus on the PostOffice process. | |||
A server composes the notification as a JSON packet containing whatever content the client should expect. (Remember, notification content is specific to the client.) It then serializes the JSON and encrypts using the key previously provided by the client and stores in a wrapper JSON object as the “cyphertext” element. The following exploded object shows the structure of the notification JSON object: | |||
{"body": "{\"timestamp\": 1312243342, | |||
\"token\":\"+rQAeMokXWNS14YFnJCaqoz51MngCMuVmHQ15sauyLA=\", | |||
\"IV\": \"MnegZvCCMZK5W2BbPqPc9g==\", | |||
\"ciphertext\": \"mary had a little lamb. She had it with mint jelly\", | |||
\"ttl\": 300}", | |||
"HMAC": "b03d25f5753e935bdabd1b6eca361ca9"} | |||
In case it's not clear, “body” is a serialized JSON string containing the elements: | |||
'''Timestamp''': the UTC timecode for when the notification was created. | |||
'''Token''': the subscription ID (previously sent to the server during user facing notification auth) | |||
'''IV''': decryption information (e.g. public key for AES) | |||
'''ciphertext''': the notification content string to decrypt and use. | |||
'''Ttl''': the number of seconds past the timestamp for the notification to live or be valid. Notifications past expiry will be deleted or ignored. | |||
The HMAC is hash result based on the previously sent HMAC key (also included by the client in the post auth response). | |||
The serialized JSON string can be sent to the PostOffice URL via a POST call, with the notification as the POST body. | |||