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(a)gmail.com> wrote:
On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc <scm.blanc(a)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://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> wrote:
On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
On Thu, Feb 6, 2014 at 12:28 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Wed, Feb 5, 2014 at 11:52 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc <scm.blanc(a)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(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