> Hi Ron,
>
> Thanks for the help. I made a custom built myself to
> fix the problem temperarely. Any idea when this bug
> would get fixed?
>
> Cheers,
> Leo
Hi Leo,
how did you work around the problem?
I have been looking into it, but as of yet, I haven't come up with an acceptable and backward compatible way to fix the spec and the implementation. Coincidentally, am working on the next Maintenance release of the jsr 115 spec, so this is a good time to get this resolved. I should have something worked out in the next day or so, and then we will be able to predict when a fix will be available, It you have any suggestions, please pass them along.
a partial solution (which I am not too fond of) would be to have the permission checking
code of the servlet container either do the escape encoding of any colon chars occurring
in the request uri, or to have the HttpServletRequest based constructor of the permission
do so. The application developer would need to escape encode any colon chars
occurring in the url-patterns of security-constraints.
another partial solution, would be to ignore any colon occuring within a first pattern that
would be of type exact if the colon was processed as a URLPatternList delimiter (since
exact patterns are not to be qualified). Colons occurring within qualifying exact pattens would still be a problem. for example, the following spec would still be ambiguous as to whether there are one or 2 qualifying patterns
/*:/z:/a
I also looked into redefining the delimiter to an "excluded" character according to rfc 2616, but then there is the problem of backward compatability of existing policy files.
supporting a preferred delimiter in addition to the colon would be the preferred approach, but that would require a way to determine when not to treat colons as delimiters. In order to do that I thing I would have to change the name syntax of WebResourcePermission and WebUserDataPermission, to provide a way to indicate when colons are supposed to be ignored in the permission name. when processing ld policy files, we would presume that the colons are significant and perhaps ambiguous, but for new policy files we would provide a way to indicate that the colons are to be ignored, and a way to use another delimiter, i.e., something like the following
RevisedURLPatternList ::= URLPattern |
RevisedURLPatternList left-curly-brace URLPattern
URLPatternList ::= URLPattern |
URLPatternList colon URLPattern
URLPatternSpec ::= null |
URLPattern |
colon URLPattern |
URLPatten colon URLPatternList |
URLPattern left-curly-brace RevisedURLPatternList
the "colon URLPattern" form would be used when colons are to be treated as data, if a pattern spec does not contain the alternate delimiter (e.g. left-curly-brace) then any colons would be treated as delimiters, otherwise the left-curly-brace would be used.
I think the above is mostly workable; the "colon URLPattern" form is a little awkward, and maybe should be replaced with some other way to do the same thing (i.e. indicate when colons are to be viewed as data).
Ron
[Message sent by forum member 'monzillo' (monzillo)]
http://forums.java.net/jive/thread.jspa?messageID=273218