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

Lucas Holmquist lholmqui at redhat.com
Mon Apr 7 11:47:20 EDT 2014


so i went back to look at what i had,


i don't think we need to get to complicated here,

reading the spec stuff, and this example

https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code

they show sending the pushEndpoint to the "App server",  so i think we could just use and keep it simple

it is also recommended that the channelID is never exposed to the application.


On Apr 1, 2014, at 3:34 PM, Lucas Holmquist <lholmqui at redhat.com> wrote:

> i had something,  now i forgot what it was,   need to go back and check
> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf <matzew at apache.org> wrote:
> 
>> 
>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist <lholmqui at redhat.com> wrote:
>> still exploring
>> 
>> :-) any recent thoughts on 'encodeURIComponent()' ? 
>>  
>> 
>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>> 
>>> 
>>> 
>>> 
>>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist <lholmqui at redhat.com> wrote:
>>> i might have a couple thoughts, but i need to try some things out first
>>> 
>>> Any update on that or does the solution proposed by Matzew (using  encodeURIComponent() ) could be enough ? 
>>> 
>>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>>> 
>>>> 
>>>> 
>>>> 
>>>> 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-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
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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
>>> 
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> 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/20140407/2e576197/attachment-0001.html 


More information about the aerogear-dev mailing list