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

On Wed, Feb 5, 2014 at 11:52 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > > > > On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;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(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev