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

Fri Jul 25 10:16:55 EDT 2014

On Jul 25, 2014, at 9:38 AM, Matthias Wessendorf <matzew at apache.org> wrote:

> 
> 
> 
> On Fri, Jul 25, 2014 at 3:33 PM, Bruno Oliveira <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 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> 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> wrote:
> > >
> > > —
> > > Tadeas Kriz
> > >
> > > On 25 Jul 2014, at 12:38 pm, Daniel Bevenius <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` 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> 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. 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> 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
> > >>
> > >> _______________________________________________
> > >> 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
> >
> 
> --
> 
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/442871bb/attachment-0001.html 