[aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter

[Karel Piwko]

On Fri, Jul 25, 2014 at 2:56 PM, Matthias Wessendorf 
<matzew at apache.org> wrote:
> 
>> UPS can translate {deviceToken} to EndpointURL. We just need a way 
>> how
>> to generate unique {deviceToken} on client.
> 
> that would be our own layer on-top, which is a no-go

why? it would be there anyway. Imagine that your UPS is running on 
exposed URL which is a gateway to your internal network. SP URL is 
valid only in that internal network, not visible from outside world at 
all.

So, using UPS is the only way to send the message to that URL.

> 
>  
>> Would UUID work?
>> EndpointURL can become part of JSON [1].
> 
> it was there as "simplePushEndpoint", but for stated reasons it's now 
> the deviceToken that has the URL value
> 
>  
>> 
>> 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.
> 
> not really

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