<div dir="ltr">OK, fair point.<div><br></div><div>Once I am done w/ documentation, I will get back to this - unless some else beats me to it :) </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 28, 2014 at 4:56 PM, Luke Holmquist <span dir="ltr"><<a href="mailto:lholmqui@redhat.com" target="_blank">lholmqui@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would rather not have to generate some id and then store that locally.<br>
<br>
Simple push is not the only thing the uses the UPS client.<br>
<br>
Sent from my iPhone<br>
<div class="HOEnZb"><div class="h5"><br>
> On Jul 28, 2014, at 3:36 AM, Karel Piwko <kpiwko@ .com> wrote:<br>
><br>
> Yes, that was it. And you're right, it indeed makes better sense to<br>
> generate UUID by client, not by server.<br>
><br>
> Karel<br>
><br>
><br>
><br>
> On Fri, Jul 25, 2014 at 3:19 PM, Matthias Wessendorf<br>
> <<a href="mailto:matzew@apache.org">matzew@apache.org</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Fri, Jul 25, 2014 at 3:06 PM, Karel Piwko <<a href="mailto:kpiwko@redhat.com">kpiwko@redhat.com</a>><br>
>> wrote:<br>
>>> On Fri, Jul 25, 2014 at 2:56 PM, Matthias Wessendorf<br>
>>> <<a href="mailto:matzew@apache.org">matzew@apache.org</a>> wrote:<br>
>>>><br>
>>>>> UPS can translate {deviceToken} to EndpointURL. We just need a way<br>
>>>>> how<br>
>>>>> to generate unique {deviceToken} on client.<br>
>>>><br>
>>>> that would be our own layer on-top, which is a no-go<br>
>>><br>
>>> why? it would be there anyway. Imagine that your UPS is running on<br>
>>> exposed URL which is a gateway to your internal network. SP URL is<br>
>>> valid only in that internal network, not visible from outside world<br>
>>> at<br>
>>> all.<br>
>>><br>
>>> So, using UPS is the only way to send the message to that URL.<br>
>><br>
>> Hrm... let's see if I am following you. Let's try:<br>
>><br>
>> If the UPS has a mapping between "magic_UUID" and endpointURL, that<br>
>> means the client layer (e.g. UPS.js) has to store this UUID<br>
>> somewhere, for unregistration.<br>
>><br>
>> Instead of having the UPS generating the UUID, it could be generated<br>
>> by the UPS.js, and its JS callback would/could return it (so that the<br>
>> JS app has it handy for later unregister).<br>
>><br>
>> That would mean the JS client would sending down the same JSON as<br>
>> before, right ?<br>
>><br>
>> deviceToken: client_side_generated_UUID,<br>
>> pushEndpoint: someURL<br>
>><br>
>><br>
>> Did I get it ?<br>
>><br>
>><br>
>><br>
>>><br>
>>>><br>
>>>><br>
>>>>> Would UUID work?<br>
>>>>> EndpointURL can become part of JSON [1].<br>
>>>><br>
>>>> it was there as "simplePushEndpoint", but for stated reasons it's<br>
>>> now<br>
>>>> the deviceToken that has the URL value<br>
>>>><br>
>>>><br>
>>>>><br>
>>>>> Such change would mean that clients can't use SP server directly<br>
>>> but<br>
>>>>> have to go through UPS. This makes more sense then current setup<br>
>>> to<br>
>>>>> me.<br>
>>>><br>
>>>> not really<br>
>>><br>
>>> See reason stated above.<br>
>>>><br>
>>>>><br>
>>>>> Karel<br>
>>>>><br>
>>>>> [1]<br>
>>> <a href="https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L74" target="_blank">https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L74</a><br>
>>>>><br>
>>>>> On Fri, Jul 25, 2014 at 1:04 PM, Matthias Wessendorf<br>
>>>>> <<a href="mailto:matzew@apache.org">matzew@apache.org</a>> wrote:<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> On Fri, Jul 25, 2014 at 12:25 PM, Tadeas Kriz <<a href="mailto:tkriz@redhat.com">tkriz@redhat.com</a>><br>
>>>>>> wrote:<br>
>>>>>>><br>
>>>>>>> —<br>
>>>>>>> Tadeas Kriz<br>
>>>>>>><br>
>>>>>>> On 25 Jul 2014, at 11:04 am, Daniel Bevenius<br>
>>>>>>> <<a href="mailto:daniel.bevenius@gmail.com">daniel.bevenius@gmail.com</a>> wrote:<br>
>>>>>>><br>
>>>>>>>>> 5. don’t use the url as a deviceToken (might not comply<br>
>>> with<br>
>>>>>>>> Mozzila’s SimplePush specs)<br>
>>>>>>>> The deviceToken is an UPS concept and there is nothing in the<br>
>>>>>>>> SimplePush spec which is violated in this case.<br>
>>>>>>> I thought that deviceTokens were changed from a generated<br>
>>> value to<br>
>>>>>>> the URL just to comply with Mozzila’s SimplePush specs.<br>
>>>>>><br>
>>>>>> Nope<br>
>>>>>><br>
>>>>>>> Matzew, why was the generated token removed then?<br>
>>>>>><br>
>>>>>> It was the channelID before - but that should not be exposed.<br>
>>>>>> In GCM devices are identified via registrationID<br>
>>>>>> In APNs devices are identified va deviceToken<br>
>>>>>> (both are somewhat the same - but different names)<br>
>>>>>><br>
>>>>>> In SimplePush devices are identifeid v/ the URL of the<br>
>>> pushEndpoint<br>
>>>>>> (a backend uses that endpoint to notify _THAT_ client,<br>
>>> regardless<br>
>>>>> of<br>
>>>>>> how many channels it has subscribed)<br>
>>>>>><br>
>>>>>> So, that lead us to make the change (see history of this threa)<br>
>>>>>><br>
>>>>>> -M<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>>><br>
>>>>>>>> I'm not sure about what the best option is for UPS thought.<br>
>>>>> Would a<br>
>>>>>>>> regex in for the @Path annotation work perhaps, something<br>
>>> like:<br>
>>>>>>>><br>
>>>>>>>> @DELETE<br>
>>>>>>>> @Path("{token, .+}")<br>
>>>>>>>> public Response unregisterInstallations(<br>
>>>>>>><br>
>>>>>>> What do you mean by that regex? The problem is simply the<br>
>>>>> “%2F”<br>
>>>>>>> in the token (which is an URLencoded simplepush url) and it’s<br>
>>>>>>> being revoked long before it hits the RestEasy (which does the<br>
>>>>>>> routing according to what’s in the @Path).<br>
>>>>>>><br>
>>>>>>>><br>
>>>>>>>>> On 25 July 2014 10:32, Tadeas Kriz <<a href="mailto:tkriz@redhat.com">tkriz@redhat.com</a>> wrote:<br>
>>>>>>>>><br>
>>>>>>>>> —<br>
>>>>>>>>> Tadeas Kriz<br>
>>>>>>>>><br>
>>>>>>>>> On 24 Jul 2014, at 05:44 pm, Karel Piwko <<a href="mailto:kpiwko@redhat.com">kpiwko@redhat.com</a>><br>
>>>>> wrote:<br>
>>>>>>>>><br>
>>>>>>>>>> On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz<br>
>>>>> <<a href="mailto:tkriz@redhat.com">tkriz@redhat.com</a>><br>
>>>>>>>>> wrote:<br>
>>>>>>>>>>><br>
>>>>>>>>>>> It should not. For hibernate, it’s just a string like<br>
>>> any<br>
>>>>>>>>> other.<br>
>>>>>>>>>>> The problem might be in the configuration of<br>
>>>>> <a href="http://JAX.RS/RestEasy" target="_blank">JAX.RS/RestEasy</a>. If<br>
>>>>>>>>>>> I’ll have some time today evening, I’ll try to fix<br>
>>> it, it<br>
>>>>>>>>> should<br>
>>>>>>>>>>> be an easy fix.<br>
>>>>>>>>>><br>
>>>>>>>>>> Last famous words? ;-)<br>
>>>>>>>>><br>
>>>>>>>>> I shall never say “an easy fix” again.<br>
>>>>>>>>><br>
>>>>>>>>>> But I agree. Everything is string and URL encode should<br>
>>>>> happen on<br>
>>>>>>>>>> client while server should automatically decode and work<br>
>>>>> always<br>
>>>>>>>>> with<br>
>>>>>>>>>> just decoded string. If we need to encode twice, something<br>
>>> is<br>
>>>>>>>>> wrong.<br>
>>>>>>>>><br>
>>>>>>>>> Anyway, the 400 Bad request response is made by the tomcat<br>
>>>>> itself,<br>
>>>>>>>>> disallowing the use of %2F as a path parameter. This will<br>
>>>>> probably<br>
>>>>>>>>> apply on other web containers.<br>
>>>>>>>>><br>
>>>>>>>>> Possible solutions with their disadvantages:<br>
>>>>>>>>><br>
>>>>>>>>> 1. well-documented double-encoding of the URL (might be<br>
>>>>> confusing)<br>
>>>>>>>>> 2. use @QueryParam instead of @PathParam (breaks the api<br>
>>>>>>>>> consistence, as every other call would still use @PathParam)<br>
>>>>>>>>> 3. allow @QueryParam (again, breaks the api consistence, but<br>
>>>>> only<br>
>>>>>>>>> for the SimplePush)<br>
>>>>>>>>> 4. find another encoding (Base64 for URL = URLEncode then<br>
>>> Base64<br>
>>>>>>>>> encode)<br>
>>>>>>>>> 5. don’t use the url as a deviceToken (might not comply<br>
>>> with<br>
>>>>>>>>> Mozzila’s SimplePush specs)<br>
>>>>>>>>><br>
>>>>>>>>> What do you think guys?<br>
>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>> _______________________________________________<br>
>>>>>>>>>> aerogear-dev mailing list<br>
>>>>>>>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> _______________________________________________<br>
>>>>>>>>> aerogear-dev mailing list<br>
>>>>>>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>>>>>><br>
>>>>>>>> _______________________________________________<br>
>>>>>>>> aerogear-dev mailing list<br>
>>>>>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> _______________________________________________<br>
>>>>>>> aerogear-dev mailing list<br>
>>>>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> --<br>
>>>>>> Matthias Wessendorf<br>
>>>>>><br>
>>>>>> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
>>>>>> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
>>>>>> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
>>>>><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> aerogear-dev mailing list<br>
>>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> Matthias Wessendorf<br>
>>>><br>
>>>> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
>>>> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
>>>> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> aerogear-dev mailing list<br>
>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>><br>
>><br>
>><br>
>> --<br>
>> Matthias Wessendorf<br>
>><br>
>> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
>> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
>> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
><br>
><br>
> _______________________________________________<br>
> aerogear-dev mailing list<br>
> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br>
<br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div>