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 https://wiki.mozilla.org/WebAPI/SimplePush/Protocol ,
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]
https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L74

On Fri, Jul 25, 2014 at 1:04 PM, Matthias Wessendorf
<matzew@apache.org> wrote:
>
>
>
> On Fri, Jul 25, 2014 at 12:25 PM, Tadeas Kriz <tkriz@redhat.com>
> wrote:
>>
>> —
>> Tadeas Kriz
>>
>> On 25 Jul 2014, at 11:04 am, Daniel Bevenius
>> <daniel.bevenius@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@redhat.com> wrote:
>>>>
>>>> —
>>>> Tadeas Kriz
>>>>
>>>> On 24 Jul 2014, at 05:44 pm, Karel Piwko <kpiwko@redhat.com> wrote:
>>>>
>>>> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz <tkriz@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@lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev