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

[Matthias Wessendorf]

On Fri, Jul 25, 2014 at 2:49 PM, Karel Piwko <kpiwko at redhat.com> wrote:

> 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?


It is not really exposed via UPS...


> As UPS is *THE* application to
> which EndpointURL is exposed to.
>

right, that's why we store it there :) In order to have the UPS trigger the
updates (using the URL)


>
> 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



> 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


>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/422703ca/attachment.html