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

[Karel Piwko]

Yes, that was it. And you're right, it indeed makes better sense to 
generate UUID by client, not by server.

Karel



On Fri, Jul 25, 2014 at 3:19 PM, Matthias Wessendorf 
<matzew at apache.org> wrote:
> 
> 
> 
> On Fri, Jul 25, 2014 at 3:06 PM, Karel Piwko <kpiwko at redhat.com> 
> wrote:
>> 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.
> 
> Hrm... let's see if I am following you. Let's try:
> 
> 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.
> 
> 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).
> 
> That would mean the JS client would sending down the same JSON as 
> before, right ?
> 
> deviceToken: client_side_generated_UUID,
> pushEndpoint: someURL
> 
> 
> Did I get it ? 
> 
> 
>  
>> 
>> >
>> >
>> >> 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
>> 
>> 
>> _______________________________________________
>> 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