[aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter
Sebastien Blanc
scm.blanc at gmail.com
Tue Feb 11 13:15:18 EST 2014
Ok,
I've been doing some tests by using the PushEndpoint as device token. For
registration it works but I just faced an issue by trying to unregister
because the URL for the DELETE looks like :
https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id[
And the REST endpoint get a bit crazy by the extra "/" present in the
endpoint URL. Therefore, I think we must just use the last URL fragment as
deviceToken.
On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>
>
> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc <scm.blanc at gmail.com>wrote:
>
>>
>>
>>
>> On Thu, Feb 6, 2014 at 12:28 PM, Matthias Wessendorf <matzew at apache.org>wrote:
>>
>>>
>>>
>>>
>>> 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.
>>>
>>
>> After reading your comment on the PR
>> https://github.com/aerogear/aerogear-js/pull/105#issuecomment-34324732 I
>> understand that you just want to use the deviceToken and not pass the
>> simplePushEndpoint to UPS anymore, is that right ?
>>
>
>
> yep
>
>
>
>
>
>
>
>
>>
>>>
>>> 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
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140211/8ef6106f/attachment-0001.html
More information about the aerogear-dev
mailing list