Re: What can url-pattern accept?

2008-08-20 Thread Guojun Zhu
I ended up with something interesting with tomcat.

I basically have two security-constraint, in the first one I put
url-pattern*.do/url-pattern and in the second one, I put
url-pattern/admin/*/url-pattern.  Tomcat just did what I want, the user
with role matching the first constraint does not have access to anything
/admin/*.  It works in both Tomcat 5.5 and 6.0.  It is probably not the
specification complied solution.  But good enough for me now.



On Sun, Aug 17, 2008 at 6:27 PM, Bill Barker [EMAIL PROTECTED] wrote:


 André Warnier [EMAIL PROTECTED] wrote in message
 news:[EMAIL PROTECTED]
  Guojun Zhu wrote:
  [...]
 
 
  Unfortunately, it seems that the servlet API allows only this in
  url-pattern specs :
  - A string beginning with a / character and ending with a /* suffix is
  used for path mapping.
  - A string beginning with a *. prefix is used as an extension mapping.
  - A string containing only the / character indicates the default
 servlet
  of the application. In this case the servlet path is the request URI
 minus
  the context path and the path info is null.

 Actually, I don't think that Tomcat supports url-pattern//url-pattern
 (although it clearly should under the very brain-dead wording of the spec
 here).  There seem to be other spec violations in Tomcat here, since if you
 have a one security-constraint for *.do, and another one for /admin/*, then
 Tomcat considers both of them for a request to /myapp/admin/foo.do.
 However, the spec (at least for v2.5) says that only the /admin/*
 constraint
 should be considered.  And this is where the brain-dead part kicks in :(,
 since Tomcat's implementation makes more sense than the spec.  Hopefully
 someone will fix this in the Servlet 3.0 spec.

  - All other strings are used for exact matches only.
 
  In other words, /admin/*.do is not a valid way to match what you want,
  since it will match only /admin/*.do, literally.
 
  For 20 years at least, there have been 2 widely-used pattern-matching
  variations in existence :
  - the file glob kind of pattern, where * anywhere matches any number
  of characters and ? anywhere matches one character
  - regular expressions
  Why the designers of the servlet API found it useful or necessary to
  invent yet their own different way of matching wildcards, and a rather
  brain-dead one at that, is beyond me.
  But so it seems to be.
 
  This being said, it seems that there exists a servlet filter which
  allows much more flexibility.  I have not tried it myself yet, but I have
  seen a lot of nice things written about it.
  Check out : http://tuckey.org/urlrewrite/
 
  André
 
  -
  To start a new topic, e-mail: users@tomcat.apache.org
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 




 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




What can url-pattern accept?

2008-08-17 Thread Guojun Zhu
Hi,

I am usging tomcat 5.5.26 and trying to set up some container security with
it.  I am using struts 1.2.9 for my project.  Basically I have three-type
links

1.  open to everyone, like the welcome pages.

2.  restricted to one type of user role, say A

3.  admin part, more restrictive, so for role B

I set a normal user only has role A, while an administrator user has both
role A and role B.  However, I have some difficulty to set up the
url-pattern for security-constraint in web.xml.  Both part 2 and 3 are
realized by struts, part 2 takes the root address, such as /doAction1.do,
etc; part 3 takes the admin subdirectory, such as /admin/user.do.  I tried
to set part 2 for url-pattern/*.do/url-pattern and part 3 for
url-pattern/admin/*.do/url-patter.  Tomcat refuses to parse it.  I know
url-pattern can do things like /admin/* for path or *.do for the
extention match.  Any other more finer things?

One ugly solution I can think is to change all the part 2 into a path like
/normal then put that part as /normal/*.  But I would perfer not to do that
since that invole lots of changes in strut-config.xml.   Any other
solution?

Thank in advance!

Sincerely
Zhu, Guojun


Re: What can url-pattern accept?

2008-08-17 Thread André Warnier

Guojun Zhu wrote:
[...]



Unfortunately, it seems that the servlet API allows only this in 
url-pattern specs :

- A string beginning with a / character and ending with a /* suffix is
used for path mapping.
- A string beginning with a *. prefix is used as an extension mapping.
- A string containing only the / character indicates the default 
servlet of the application. In this case the servlet path is the request 
URI minus the context path and the path info is null.

- All other strings are used for exact matches only.

In other words, /admin/*.do is not a valid way to match what you want, 
since it will match only /admin/*.do, literally.


For 20 years at least, there have been 2 widely-used pattern-matching 
variations in existence :
- the file glob kind of pattern, where * anywhere matches any number 
of characters and ? anywhere matches one character

- regular expressions
Why the designers of the servlet API found it useful or necessary to 
invent yet their own different way of matching wildcards, and a rather 
brain-dead one at that, is beyond me.

But so it seems to be.

This being said, it seems that there exists a servlet filter which 
allows much more flexibility.  I have not tried it myself yet, but I 
have seen a lot of nice things written about it.

Check out : http://tuckey.org/urlrewrite/

André

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: What can url-pattern accept?

2008-08-17 Thread Bill Barker

André Warnier [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
 Guojun Zhu wrote:
 [...]


 Unfortunately, it seems that the servlet API allows only this in 
 url-pattern specs :
 - A string beginning with a / character and ending with a /* suffix is
 used for path mapping.
 - A string beginning with a *. prefix is used as an extension mapping.
 - A string containing only the / character indicates the default servlet 
 of the application. In this case the servlet path is the request URI minus 
 the context path and the path info is null.

Actually, I don't think that Tomcat supports url-pattern//url-pattern 
(although it clearly should under the very brain-dead wording of the spec 
here).  There seem to be other spec violations in Tomcat here, since if you 
have a one security-constraint for *.do, and another one for /admin/*, then 
Tomcat considers both of them for a request to /myapp/admin/foo.do. 
However, the spec (at least for v2.5) says that only the /admin/* constraint 
should be considered.  And this is where the brain-dead part kicks in :(, 
since Tomcat's implementation makes more sense than the spec.  Hopefully 
someone will fix this in the Servlet 3.0 spec.

 - All other strings are used for exact matches only.

 In other words, /admin/*.do is not a valid way to match what you want, 
 since it will match only /admin/*.do, literally.

 For 20 years at least, there have been 2 widely-used pattern-matching 
 variations in existence :
 - the file glob kind of pattern, where * anywhere matches any number 
 of characters and ? anywhere matches one character
 - regular expressions
 Why the designers of the servlet API found it useful or necessary to 
 invent yet their own different way of matching wildcards, and a rather 
 brain-dead one at that, is beyond me.
 But so it seems to be.

 This being said, it seems that there exists a servlet filter which 
 allows much more flexibility.  I have not tried it myself yet, but I have 
 seen a lot of nice things written about it.
 Check out : http://tuckey.org/urlrewrite/

 André

 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

 




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]