On Jul 25, 2014, at 10:29 AM, Matthias Wessendorf <matzew@apache.org> wrote:On Fri, Jul 25, 2014 at 4:16 PM, Lucas Holmquist <lholmqui@redhat.com> wrote:
On Jul 25, 2014, at 9:38 AM, Matthias Wessendorf <matzew@apache.org> wrote:On Fri, Jul 25, 2014 at 3:33 PM, Bruno Oliveira <bruno@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 ChromeI 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 suredidn’t realize anything is sent back, in our examples, using UPS.js, we don’t do anything with the returned value
_______________________________________________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@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@redhat.com> wrote:
> >
> > —
> > Tadeas Kriz
> >
> > On 25 Jul 2014, at 12:38 pm, Daniel Bevenius <daniel.bevenius@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@redhat.com> wrote:
> >>
> >> —
> >> Tadeas Kriz
> >>
> >> On 25 Jul 2014, at 11:04 am, Daniel Bevenius <daniel.bevenius@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@redhat.com> wrote:
> >>>
> >>> —
> >>> Tadeas Kriz
> >>>
> >>> On 24 Jul 2014, at 05:44 pm, Karel Piwko <kpiwko@redhat.com> wrote:
> >>>
> >>> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz <tkriz@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@lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>
> >>>
> >>> _______________________________________________
> >>> aerogear-dev mailing list
> >>> aerogear-dev@lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>
> >>> _______________________________________________
> >>> aerogear-dev mailing list
> >>> aerogear-dev@lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
abstractj
PGP: 0x84DC9914_______________________________________________
aerogear-dev mailing list
aerogear-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev