Long term, we want an implementation that works on all servers. If some
of them reject path params with '/', we need to token encode it somehow.
According to
,
EndpointURL should be exposed to application. Which does not mean that
it must be exposed to via UPS, right? As UPS is *THE* application to
which EndpointURL is exposed to.
UPS can translate {deviceToken} to EndpointURL. We just need a way how
to generate unique {deviceToken} on client. Would UUID work?
EndpointURL can become part of JSON [1].
Such change would mean that clients can't use SP server directly but
have to go through UPS. This makes more sense then current setup to me.
Karel
[1]
On Fri, Jul 25, 2014 at 1:04 PM, Matthias Wessendorf
<matzew(a)apache.org> wrote:
On Fri, Jul 25, 2014 at 12:25 PM, Tadeas Kriz <tkriz(a)redhat.com>
wrote:
>
> —
> Tadeas Kriz
>
> On 25 Jul 2014, at 11:04 am, Daniel Bevenius
> <daniel.bevenius(a)gmail.com> wrote:
>
>> >5. don’t use the url as a deviceToken (might not comply with
>> Mozzila’s SimplePush specs)
>> The deviceToken is an UPS concept and there is nothing in the
>> SimplePush spec which is violated in this case.
>>
> I thought that deviceTokens were changed from a generated value to
> the URL just to comply with Mozzila’s SimplePush specs.
Nope
> Matzew, why was the generated token removed then?
It was the channelID before - but that should not be exposed.
In GCM devices are identified via registrationID
In APNs devices are identified va deviceToken
(both are somewhat the same - but different names)
In SimplePush devices are identifeid v/ the URL of the pushEndpoint
(a backend uses that endpoint to notify _THAT_ client, regardless of
how many channels it has subscribed)
So, that lead us to make the change (see history of this threa)
-M
>
>> I'm not sure about what the best option is for UPS thought. Would a
>> regex in for the @Path annotation work perhaps, something like:
>>
>> @DELETE
>> @Path("{token, .+}")
>> public Response unregisterInstallations(
>>
>
> What do you mean by that regex? The problem is simply the “%2F”
> in the token (which is an URLencoded simplepush url) and it’s
> being revoked long before it hits the RestEasy (which does the
> routing according to what’s in the @Path).
>
>>
>> On 25 July 2014 10:32, Tadeas Kriz <tkriz(a)redhat.com> wrote:
>>>
>>> —
>>> Tadeas Kriz
>>>
>>> On 24 Jul 2014, at 05:44 pm, Karel Piwko <kpiwko(a)redhat.com> wrote:
>>>
>>> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz <tkriz(a)redhat.com>
>>> wrote:
>>> >>
>>> >> It should not. For hibernate, it’s just a string like any
>>> other.
>>> >> The problem might be in the configuration of JAX.RS/RestEasy. If
>>> >> I’ll have some time today evening, I’ll try to fix it, it
>>> should
>>> >> be an easy fix.
>>> >
>>> > Last famous words? ;-)
>>> >
>>>
>>> I shall never say “an easy fix” again.
>>>
>>> > But I agree. Everything is string and URL encode should happen on
>>> > client while server should automatically decode and work always
>>> with
>>> > just decoded string. If we need to encode twice, something is
>>> wrong.
>>> >
>>>
>>> Anyway, the 400 Bad request response is made by the tomcat itself,
>>> disallowing the use of %2F as a path parameter. This will probably
>>> apply on other web containers.
>>>
>>> Possible solutions with their disadvantages:
>>>
>>> 1. well-documented double-encoding of the URL (might be confusing)
>>> 2. use @QueryParam instead of @PathParam (breaks the api
>>> consistence, as every other call would still use @PathParam)
>>> 3. allow @QueryParam (again, breaks the api consistence, but only
>>> for the SimplePush)
>>> 4. find another encoding (Base64 for URL = URLEncode then Base64
>>> encode)
>>> 5. don’t use the url as a deviceToken (might not comply with
>>> Mozzila’s SimplePush specs)
>>>
>>> What do you think guys?
>>>
>>> >>
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > 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
>>
>> _______________________________________________
>> 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