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

Fri Jul 25 12:44:07 EDT 2014

On Friday, July 25, 2014, Lucas Holmquist <lholmqui at redhat.com> wrote:

>
> On Jul 25, 2014, at 10:29 AM, Matthias Wessendorf <matzew at apache.org
> <javascript:_e(%7B%7D,'cvml','matzew at apache.org');>> wrote:
>
>
>
>
> On Fri, Jul 25, 2014 at 4:16 PM, Lucas Holmquist <lholmqui at redhat.com
> <javascript:_e(%7B%7D,'cvml','lholmqui at redhat.com');>> wrote:
>
>>
>> On Jul 25, 2014, at 9:38 AM, Matthias Wessendorf <matzew at apache.org
>> <javascript:_e(%7B%7D,'cvml','matzew at apache.org');>> wrote:
>>
>>
>>
>>
>> On Fri, Jul 25, 2014 at 3:33 PM, Bruno Oliveira <bruno at abstractj.org
>> <javascript:_e(%7B%7D,'cvml','bruno at abstractj.org');>> wrote:
>>
>>> Hi Tadeas, you are correct. Apache web server disallow %2F or %5C
>>> due to security concerns. There are several alternatives, most of them
>>> workarouds, some people double encode it, others replace / by _ back and
>>> forth or some people disable it like:
>>>
>>> <VirtualHost *:80>
>>>     AllowEncodedSlashes On
>>> </VirtualHost>
>>>
>>
>> so, looks like it was a stupid idea to use the pushEndpoint as the
>> 'deviceToken'.
>>
>> Perhaps we should make UPS.js generate a UUID and use that as deviceToken
>> and send the pushEndpoint as part of the JSON, similar to like we did
>> before.
>> (But before we were using the SimplePush channelID as the deviceToken,
>> which is clearly a no-go)
>>
>>
>> i’ll need to look into this more,  but i sort of like the fact that the
>> UPS.js is somewhat stateless and doesn’t care about SimplePush,  since it
>> is also used for GCM for Chrome
>>
>
>
> I can see that - but ... thinking... I'd also like to get rid of returning
> any payload from the registration endpoint.  I think some of the
> simplifications in simplepush are part of the issue. not sure
>
> didn’t realize anything is sent back,  in our examples,  using UPS.js,  we
> don’t do anything with the returned value
>

Yep, dont rely on it

>
>
>
> I like it, but it's just different :)
>
>>
>>
>>
>>>
>>> I hope it helps, otherwise let me know how I can help.
>>>
>>> On 2014-07-25, Tadeas Kriz wrote:
>>> >
>>> > —
>>> > Tadeas Kriz
>>> >
>>> > On 25 Jul 2014, at 01:09 pm, Daniel Bevenius <
>>> daniel.bevenius at gmail.com
>>> <javascript:_e(%7B%7D,'cvml','daniel.bevenius at gmail.com');>> wrote:
>>> >
>>> > > > it might work, although I’m not sure if this is the best solution
>>> “on the market”.
>>> > > It may not be the best solution and feel free to ignore it.
>>> > >
>>> >
>>> > I’d love to test it first. My only concern is whether or not might it
>>> be a security issue. I think that’s something that Bruno might know.
>>> >
>>> > >
>>> > >
>>> > >
>>> > > On 25 July 2014 12:55, Tadeas Kriz <tkriz at redhat.com
>>> <javascript:_e(%7B%7D,'cvml','tkriz at redhat.com');>> wrote:
>>> > >
>>> > > —
>>> > > Tadeas Kriz
>>> > >
>>> > > On 25 Jul 2014, at 12:38 pm, Daniel Bevenius <
>>> daniel.bevenius at gmail.com
>>> <javascript:_e(%7B%7D,'cvml','daniel.bevenius at gmail.com');>> wrote:
>>> > >
>>> > >> >What do you mean by that regex?
>>> > >> That the JAXRS implementation should not disallow as '/' in the
>>> path.
>>> > >
>>> > > Well, if it was like:
>>> > >
>>> > > ```
>>> > > DELETE /rest/registry/installation/http://localhost:8321/asdasd
>>> > > ```
>>> > >
>>> > > and the token you showed would match all the characters (which means
>>> that the `String token` would become `http://localhost:8321/asdasd`
>>> <http://localhost:8321/asdasd> in the endpoint method), it might work,
>>> although I’m not sure if this is the best solution “on the market”.
>>> > >
>>> > >>
>>> > >> >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).
>>> > >> I guess I don't understand why this would be revoked by anything
>>> before it hits the JAXRS implementation, but if that is the case you are
>>> right and adding this would not help.
>>> > >>
>>> > >
>>> > > This was a solution for a security hole. As I understand it, on
>>> linux, scripts cannot tell difference between “/“ and “%2F” and because of
>>> that, it’s forbidden to use as a path parameter (at least on Tomcat).
>>> > >
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >> On 25 July 2014 12:25, Tadeas Kriz <tkriz at redhat.com
>>> <javascript:_e(%7B%7D,'cvml','tkriz at redhat.com');>> wrote:
>>> > >>
>>> > >> —
>>> > >> Tadeas Kriz
>>> > >>
>>> > >> On 25 Jul 2014, at 11:04 am, Daniel Bevenius <
>>> daniel.bevenius at gmail.com
>>> <javascript:_e(%7B%7D,'cvml','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. Matzew, why was the
>>> generated token removed then?
>>> > >>
>>> > >>> 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
>>> <javascript:_e(%7B%7D,'cvml','tkriz at redhat.com');>> wrote:
>>> > >>>
>>> > >>> —
>>> > >>> Tadeas Kriz
>>> > >>>
>>> > >>> On 24 Jul 2014, at 05:44 pm, Karel Piwko <kpiwko at redhat.com
>>> <javascript:_e(%7B%7D,'cvml','kpiwko at redhat.com');>> wrote:
>>> > >>>
>>> > >>> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz <tkriz at redhat.com
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <http://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
>>> <javascript:_e(%7B%7D,'cvml','aerogear-dev at lists.jboss.org');>
>>> > >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> > >>>
>>> > >>>
>>> > >>> _______________________________________________
>>> > >>> aerogear-dev mailing list
>>> > >>> aerogear-dev at lists.jboss.org
>>> <javascript:_e(%7B%7D,'cvml','aerogear-dev at lists.jboss.org');>
>>> > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> > >>>
>>> > >>> _______________________________________________
>>> > >>> aerogear-dev mailing list
>>> > >>> aerogear-dev at lists.jboss.org
>>> <javascript:_e(%7B%7D,'cvml','aerogear-dev at lists.jboss.org');>
>>> > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> > >>
>>> > >>
>>> > >> _______________________________________________
>>> > >> aerogear-dev mailing list
>>> > >> aerogear-dev at lists.jboss.org
>>> <javascript:_e(%7B%7D,'cvml','aerogear-dev at lists.jboss.org');>
>>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> > >>
>>> > >> _______________________________________________
>>> > >> aerogear-dev mailing list
>>> > >> aerogear-dev at lists.jboss.org
>>> <javascript:_e(%7B%7D,'cvml','aerogear-dev at lists.jboss.org');>
>>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> > >
>>> > >
>>> > > _______________________________________________
>>> > > aerogear-dev mailing list
>>> > > aerogear-dev at lists.jboss.org
>>> <javascript:_e(%7B%7D,'cvml','aerogear-dev at lists.jboss.org');>
>>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> > >
>>> > > _______________________________________________
>>> > > aerogear-dev mailing list
>>> > > aerogear-dev at lists.jboss.org
>>> <javascript:_e(%7B%7D,'cvml','aerogear-dev at lists.jboss.org');>
>>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> >
>>>
>>> --
>>>
>>> abstractj
>>> PGP: 0x84DC9914
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','aerogear-dev at lists.jboss.org');>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','aerogear-dev at lists.jboss.org');>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>

-- 
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/0cd50549/attachment-0001.html 