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

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(a)apache.org&gt; wrote: > > On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > still exploring > > :-) any recent thoughts on 'encodeURIComponent()' ? > > > On Feb 13, 2014, at 3:39 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > >> >> >> >> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; 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(a)gmail.com&gt; wrote: >> >>> >>> >>> >>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; 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://update... [ >>> >>> 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(a)apache.org&gt; wrote: >>> >>> >>> >>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>> >>> >>> >>> On Thu, Feb 6, 2014 at 12:28 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>> >>> >>> >>> 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. >>> >>> 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(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 >>> >>> >>> _______________________________________________ >>> 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 >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev