On 5/27/10 6:44 PM, Bill Shannon wrote:
> It sucks having to invent another encoding scheme; URL encoding seems
> like the obvious answer. Are we sure we can't address the potential
> security issues another way?
>
> If we have to use a different encoding, we should at least use an
> existing reversible encoding, rather than invent a new one,
> especially a non-reversible one.
Without having given much thought to the side-effects at this point,
I've gotten this working with double encoding the resource name:
jndi%252Ffoo (for jndi/foo)
To make this work, I had to make changes in a number of places to do the
decoding. I also ran into issues with the generated XML, as "Jndi/foo"
is not a valid XML element name, so I had to convert the / to a dash,
which I did for all formats to keep things consistent.
I've pasted the diff here:
http://pastebin.com/da5hRJTD
I would appreciate a good review of this code (as well as the
approach). FWIW, I have a unit test checked in to help drive this
change, which is currently passing.
> We could encode it all in base64, but that's ugly.
Agreed.
> Possibly we could use html encoding?
The HTML encoding of '/' is '/' unless I'm missing something. :)
> Or even modified UTF-7 from RFC 3501?
I'm not familiar with that.
What about Andreas' {jndi/foo} suggestion? If we were on git with its
easy, lightweight local branches, I'd try that approach as well. As it
is, I'll wait for feedback. :)
--
Jason Lee
Senior Member of Technical Staff
GlassFish Administration Console
Oracle Corporation
Phone x31197/+1 405-343-1964
Blog http://blogs.steeplesoft.com