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>
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(a)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(a)redhat.com> wrote:
>
> —
> Tadeas Kriz
>
> On 25 Jul 2014, at 12:38 pm, Daniel Bevenius <daniel.bevenius(a)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(a)redhat.com> wrote:
>>
>> —
>> Tadeas Kriz
>>
>> On 25 Jul 2014, at 11:04 am, Daniel Bevenius <daniel.bevenius(a)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(a)redhat.com> wrote:
>>>
>>> —
>>> Tadeas Kriz
>>>
>>> On 24 Jul 2014, at 05:44 pm, Karel Piwko <kpiwko(a)redhat.com> wrote:
>>>
>>> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz <tkriz(a)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(a)lists.jboss.org
>>> >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev