It IS getting encoded (see the URL on the issue), but the decoding is
causing problems.
On 11/12/10 11:06 AM, Tom Mueller wrote:
> Shouldn't this be addressed by using URL-encoding of the resource
> name? %5c for backslash.
>
> Tom
>
> On 11/11/2010 11:26 AM, Jason Lee wrote:
>> A couple of weeks ago, I asked about backslashes in URLs. For
>> reference, this issue is driving the question:
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=13348
>>
>> The possible solutions were: modify Grizzly to allow the backslash,
>> or disallow the use of the backslash in resource names.
>>
>> I opened an issue against Grizzly
>> (https://glassfish.dev.java.net/issues/show_bug.cgi?id=14441) to
>> track the discussion on the Grizzly side. Oleksiy and I discussed
>> the issue this morning. His assessment (and correct me if I get this
>> wrong, Oleksiy) is that we can make Grizzly allow the character, but
>> the security implications are unclear. He gave this example (copied
>> from IM):
>>
>> we allow users to access folder a/b/c, but don't want them see
>> a/b/c/d
>> and if someone will try a/b/c\d - our policy may not catch this
>> request
>> and create let's say a File("a/b/c\d")
>> which will be interpreted by Windows as "a\b\c\d" and user will
>> get access to folder d
>> which wasn't allowed
>>
>> The code that disallows the character (which he pasted on #14441) has
>> been in place "for ages." We're just now hitting this issue, it
>> seems, due to our migration to REST. We can change it of course, but
>> the implications are unclear.
>>
>> Oleksiy and I would both me more comfortable with disallowing the
>> character altogether. Today, it's \, but tomorrow it could be yet
>> another exception for some as-of-yet unexpected "special" character.
>> That decision, of course, isn't ours to make, so I bring it up here.
>>
>> What's the group's opinion, then? If we feel we need to allow the
>> character and others feel there are no security concerns, we can
>> certainly do that. Disallowing the character is probably easier and
>> safer, but may not be the best for users, so I'm open to guidance
>> here. :)
>>
>> --
>> Jason Lee
>> Senior Member of Technical Staff
>> GlassFish Administration Console
>>
>> Oracle Corporation
>> Phone +1 405-216-3193
>> Bloghttp://blogs.steeplesoft.com
--
Jason Lee
Senior Member of Technical Staff
GlassFish Administration Console
Oracle Corporation
Phone +1 405-216-3193
Blog http://blogs.steeplesoft.com