<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 25, 2014 at 3:06 PM, Karel Piwko <span dir="ltr"><<a href="mailto:kpiwko@redhat.com" target="_blank">kpiwko@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">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>
</div>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 at<br>
all.<br>
<br>
So, using UPS is the only way to send the message to that URL.<br></blockquote><div><br></div><div>Hrm... let's see if I am following you. Let's try:</div><div><br></div><div>If the UPS has a mapping between "magic_UUID" and endpointURL, that means the client layer (e.g. UPS.js) has to store this UUID somewhere, for unregistration.<br>
</div><div><br></div><div>Instead of having the UPS generating the UUID, it could be generated by the UPS.js, and its JS callback would/could return it (so that the JS app has it handy for later unregister).</div><div><br>
</div><div>That would mean the JS client would sending down the same JSON as before, right ?</div><div><br></div><div>deviceToken: client_side_generated_UUID,</div><div>pushEndpoint: someURL</div><div><br></div><div><br></div>
<div>Did I get it ? </div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><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 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 but<br>
>> have to go through UPS. This makes more sense then current setup to<br>
>> me.<br>
><br>
> not really<br>
<br>
</div>See reason stated above.<br>
<div class="HOEnZb"><div class="h5">><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 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>
>> >>><br>
>> >> I thought that deviceTokens were changed from a generated 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 pushEndpoint<br>
>> > (a backend uses that endpoint to notify _THAT_ client, 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 like:<br>
>> >>><br>
>> >>> @DELETE<br>
>> >>> @Path("{token, .+}")<br>
>> >>> public Response unregisterInstallations(<br>
>> >>><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 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 it, it<br>
>> >>>> should<br>
>> >>>> >> be an easy fix.<br>
>> >>>> ><br>
>> >>>> > Last famous words? ;-)<br>
>> >>>> ><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 is<br>
>> >>>> wrong.<br>
>> >>>> ><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 Base64<br>
>> >>>> encode)<br>
>> >>>> 5. don’t use the url as a deviceToken (might not comply with<br>
>> >>>> Mozzila’s SimplePush specs)<br>
>> >>>><br>
>> >>>> What do you think guys?<br>
>> >>>><br>
>> >>>> >><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></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></div>