<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 25, 2014 at 2:49 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">Long term, we want an implementation that works on all servers. If some<br>
of them reject path params with '/', we need to token encode it somehow.<br>
<br>
According to <a href="https://wiki.mozilla.org/WebAPI/SimplePush/Protocol" target="_blank">https://wiki.mozilla.org/WebAPI/SimplePush/Protocol</a> ,<br>
EndpointURL should be exposed to application. Which does not mean that<br>
it must be exposed to via UPS, right?</blockquote><div><br></div><div>It is not really exposed via UPS...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As UPS is *THE* application to<br>
which EndpointURL is exposed to.<br></blockquote><div><br></div><div>right, that's why we store it there :) In order to have the UPS trigger the updates (using the URL)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
UPS can translate {deviceToken} to EndpointURL. We just need a way how<br>
to generate unique {deviceToken} on client.</blockquote><div><br></div><div>that would be our own layer on-top, which is a no-go</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Would UUID work?<br>
EndpointURL can become part of JSON [1].<br></blockquote><div><br></div><div>it was there as "simplePushEndpoint", but for stated reasons it's now the deviceToken that has the URL value</div><div><br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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 me.<br></blockquote><div><br></div><div>not really</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
<div class="HOEnZb"><div class="h5"><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 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. 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 “%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>> wrote:<br>
>>>><br>
>>>> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz <<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 <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 happen on<br>
>>>> > client while server should automatically decode and work 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 itself,<br>
>>>> disallowing the use of %2F as a path parameter. This will 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 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 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></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>