[aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter

[Matthias Wessendorf]

On Wed, Feb 5, 2014 at 11:52 PM, Matthias Wessendorf <matzew at apache.org>wrote:

>
>
>
> On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc <scm.blanc at gmail.com>wrote:
>
>> Hi,
>> While playing today with my Firefox Device and its native Simple Push
>> support I noticed  some differences between our implementation and the
>> native Push regarding the success callback after a register :
>>
>>
>>
>>
>>
>> //Native FFOS Push
>> broadcastRequest = navigator.push.register();
>> broadcastRequest.onsuccess = function (event) {
>>       broadcastEndpoint = broadcastRequest.result; // only contains the pushURL
>>  }
>>
>>
>> //Aerogear Push Adapter
>> broadcastRequest = navigator.push.register();
>> broadcastRequest.onsuccess = function (event) {
>>       broadcastEndpoint = broadcastRequest.result.pushEndpoint;
>>       channelID = broadcastRequest.result.channelID;
>>       version = broadcastRequest.result.version;
>>       status = broadcastRequest.result.status
>>  }
>>
>> So, the AeroGear Push exposes much more in the callback that it should
>> suppose to do : just exposing the pushEndpoint.
>>
>> The reason we do that I suppose, but Luke or Kris could confirm that, is
>> that we thought respecting the SPS protocol, which indeed returns a whole
>> object containing all the info. It is just that the Native Push Client API
>> filter that out in the callback response.
>>
>
>
> Did they change that recently? Or was theirs always like it is now ?
>
>
>
>>  After discussing that on the #push channel with the Mozilla people they
>> confirmed me that we should only expoe the pushEndpoint.
>>
>
>
> yep, I agree on changing our JS polyfil
>
>
>
>>
>> If we keep it as is, this can be problematic when we want to use the same
>> code both for native and with the adapter when, for instance, registering
>> to the UPS :
>>
>> broadcastRequest = navigator.push.register();
>> broadcastRequest.onsuccess = function (event) {
>>       broadcastEndpoint = event.target.result;
>>       var broadCastSettings = {
>>           metadata: {
>>               deviceToken: broadcastEndpoint.channelID,
>>               simplePushEndpoint: broadcastEndpoint.pushEndpoint
>>           }
>>        }
>>      UPClient.registerWithPushServer(broadCastSettings);
>> }
>>
>>
>>
>> This won't work with the native push since "broadcastEndpoint.channelID"
>> will be undefined.
>>
>
> sweet :-)
>
>
>>
>> So I propose that we change the behaviour, to return only the
>> pushEndpoint in the callback, even if that means a bit of String
>> manipulation when we want to perform the registration to the UPS :
>>
>> var broadCastSettings = {
>>         metadata: {
>>             deviceToken: broadcastEndpoint.substr(broadcastEndpoint.lastIndexOf('/') + 1),
>>             simplePushEndpoint: broadcastEndpoint
>>                    }
>>          }
>>
>>
>>
> well, that's not really good for security reasons, since their looooong
> 'substring' was done for that. Also that's just redundant.
>
> The I guess, the deviceToken (channelID registration) might be a bit
> bogus, for SimplePush. Let me think about it....
>


Right now we use the channelID as the deviceToken, but we should not really
'leak' the channelID (see [1]), so I guess the here proposed change makes
sense. Don't recall exactly why we did it in the past, but yeah - let's
change it.


Thinking about the consequence: I think we should use store the value of
the returned 'pushEndpoint' string as our device-token. At the end the
device-token is really the thing that identifies a device w/in the target
network. Apple/Google uses a unique string, and if Mozilla uses a URL,
that's totally fine.

Reading the protocol definitions (see [1]) for the 'endpoint' I think it is
fair to use that (unique) URL string as the device-token; And we could use
this token value as well for the unregister calls, instead of the
channelIDs.


Any thoughts ?


-Matthias

[1] https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#Definitions




>
> That said, we still have no clue how to proper clean-up 'out dated'
> channels, since the SimplePush Server/Protocol is silent on that (unlike
> APNs / GCM). but that's really a different thread (yep, we have a future
> JIRA for that)
>
>
> -M
>
>
>
>> wdyt ?
>>
>> Seb
>>
>>
>> ps : our SPS Server implementation stays correct and returns what should
>> be returned, it's really just the client part and how we expose the result
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140206/86cd5a5c/attachment.html