That should work fine. /Content/*.do will still be considered an exact
pattern, and will be matched before the *.do extension pattern (no matter
what order they appear in the web.xml file). Only stuff that doesn't match
/Content/*.do but does match *.do will be secured in the example. You could
use the default mapping / to secure everything by default, and then
explicitly make /Content/*.do and perhaps /images/*, /styles/*, etc.
publicly available by adding url-patterns for them in the unsecured
web-resource-collection. You can put more than one url-mapping element in a
web-resource-collection, so it would be easy to do.

The Servlet Spec Version 2.3, sections SRV.12 and SRV.11.1 define the
matching behavior. They are pretty short and definitely worth a read for
anyone doing security stuff. I wrote some security constraints before I read
it, and I think I would have benefitted greatly from the short read had I
done it first.

Here are the most important parts (WITH MY OWN NOTES ADDED IN ALL CAPS;
SORRY FOR SHOUTING :-0):

Matching behavior for requests (from the servlet section, but the same rules
are applied for checking url-patterns for security):
1. The container will try to find an exact match of the path of the request
to the path of the servlet. A successful match selects the servlet. EXACT
PATTERNS WILL BE TRIED FIRST

2. The container will recursively try to match the longest path-prefix: This
is done by stepping down the path tree a directory at a time, using the '/'
character as a path separator. The longest match determines the servlet
selected. NOTE: 'longest' means the most path elements here -- '/a/b/c/d/*'
is longer than '/onereallylongdirectoryname/*' THEN THE PATH PATTERNS WILL
BE TRIED, STARTING WITH THE LONGEST ONES

3. If the last segment in the URL path contains an extension (e.g. .jsp),
the servlet container will try to match a servlet that handles requests for
the extension. An extension is defined as the part of the last segment after
the last '.' character. THEN THE EXTENSION PATTERNS WILL BE TRIED

4. If neither of the previous three rules result in a servlet match, the
container will attempt to serve content appropriate for the resource
requested. If a "default" servlet is defined for the application, it will be
used. AND FINALLY THE DEFAULT PATTERN WILL BE USED IF IT HAS BEEN SPECIFIED

OTHERWISE, NO MATCH -- ALLOW THE REQUEST


Classification rules for url-patterns in your web.xml file (path, extension,
default, exact):

1. A string beginning with a '/' character and ending with a '/*' postfix is
used for path mapping. PATH (INCLUDES '/*')
2. A string beginning with a '*.' prefix is used as an extension mapping.
EXTENSION

3. 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. DEFAULT

4. All other strings are used for exact matches only. IF IT DOESN'T MATCH
THE DEFINITIONS ABOVE, YOUR PATTERN IS AN EXACT PATTERN


-Max

----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, April 03, 2003 10:33 PM
Subject: RE: How to do authentication in different way for different action
classes


Would this be valid then:

   <security-constraint>
      <web-resource-collection>
         <web-resource-name>Secured Resources</web-resource-name>
         <url-pattern>*.do</url-pattern>
      </web-resource-collection>
      <auth-constraint>
         <role-name>strutsuser</role-name>
      </auth-constraint>
   </security-constraint>

   <security-constraint>
      <web-resource-collection>
         <web-resource-name>Public Resources</web-resource-name>
         <url-pattern>/Content/*.do</url-pattern>
      </web-resource-collection>
   </security-constraint>


Where /Content is a sub directory of the ROOT directory, and that
subDirectory is _NOT_ secured, but everything else _IS_ secured?

This way I do not have to put all my secured pages under /private/* and I
can just intermingle them.


-----Original Message-----
From: Max Cooper [mailto:[EMAIL PROTECTED]
Sent: Friday, April 04, 2003 3:25 AM
To: Struts Users Mailing List; [EMAIL PROTECTED]
Subject: Re: How to do authentication in different way for different
action classes


You should keep *.do for your servlet mapping.

Assuming you are using container-managed security, you can do something like
this for your security constraints:

   <security-constraint>
      <web-resource-collection>
         <web-resource-name>Secured Resources</web-resource-name>
         <url-pattern>*.do</url-pattern>
      </web-resource-collection>
      <auth-constraint>
         <role-name>strutsuser</role-name>
      </auth-constraint>
   </security-constraint>

   <security-constraint>
      <web-resource-collection>
         <web-resource-name>Public Resources</web-resource-name>
         <url-pattern>/welcome.do</url-pattern>
      </web-resource-collection>
   </security-constraint>

The servlet spec requires that "exact" patterns like /welcome.do should be
matched before "extension" patterns like *.do. So, requests for /welcome.do
will match the security constraint that doesn't have any role requirements,
rather than the one that does.

-Max

----- Original Message -----
From: "Rajendra Kadam" <[EMAIL PROTECTED]>
To: "Struts-User" <[EMAIL PROTECTED]>
Sent: Thursday, April 03, 2003 4:23 PM
Subject: How to do authentication in different way for different action
classes


> Hi,
>
> In our application,
>
> I don't want to do authentication to first action class ( welcome.do )
> But at the same time, I want to do authetication for all other action
> classes.
>
> Initally my web.xml was looking like this
>
>   <servlet>
>     <servlet-name>action</servlet-name>
>
> <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
>     ......
>   </servlet>
>
>   <servlet-mapping>
>    <servlet-name>action</servlet-name>
>    <url-pattern>*.do</url-pattern>
>   </servlet-mapping>
>
> But the disadvantage of doing this way, is that Authentication Dialog
> box comes up for welcome.do also. Which I don't want.
>
> Hence right now I'm putting all action classes for which authentication
> is required into url-pattern as shown below :
>
>   <servlet-mapping>
>    <servlet-name>action</servlet-name>
>    <url-pattern>/abc.do</url-pattern>
>    <url-pattern>/xya.do</url-pattern>
>    <url-pattern>/sdabc.do</url-pattern>
>           ......
>   </servlet-mapping>
>
> Since I had not mentioned, welcome.do in above place, it doesn't do
> authentication for it.
>
> Dis-advantage of doing this is everytime I added new Action class, I
> have to make the entry into this url-pattern.
>
> Is there any better way of doing this ?
>
> TIA,
> raju
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
should not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses.  The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission.  If
verification is required please request a hard-copy version.  This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to