i might have a couple thoughts, but i need to try some things out first
On Feb 12, 2014, at 3:53 AM, Sebastien Blanc <scm.blanc@gmail.com> wrote:




On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc <scm.blanc@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 : 


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@apache.org> wrote:



On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc <scm.blanc@gmail.com> wrote:



On Thu, Feb 6, 2014 at 12:28 PM, Matthias Wessendorf <matzew@apache.org> wrote:



On Wed, Feb 5, 2014 at 11:52 PM, Matthias Wessendorf <matzew@apache.org> wrote:



On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc <scm.blanc@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






 


 

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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev