[aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter
Sebastien Blanc
scm.blanc at gmail.com
Wed Feb 12 03:53:33 EST 2014
On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc <scm.blanc at gmail.com>wrote:
> 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.
>
Ok answering to myself ;) That won't work neither since if we do that UPS
won't have the compllete push endpoint URL.
So how do we deal with that ?
>
>
> 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-34324732I 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/20140212/c4da885f/attachment-0001.html
More information about the aerogear-dev
mailing list