Hi Max,
Thanks for a explaining this in great detail.
Still I'm not able to solve my issue.
Here is problem with more description :
My current web.xml looks like :
<security-constraint>
<web-resource-collection>
<web-resource-name>CCO</web-resource-name>
<url-pattern>/login.do</url-pattern>
<url-pattern>/pim/requestAdmin.do</url-pattern>
<http-method>DELETE</http-method>
<http-method>POST</http-method>
<http-method>GET</http-method>
<http-method>PUT</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>Public Resources</web-resource-name>
<url-pattern>/pim/welcome.do</url-pattern>
</web-resource-collection>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>CCO</realm-name>
</login-config>
But now authentication dialog pops up for welcome.do also. Do I missing
something here ?
Also one thing I want to mention here, we don't much care about
role-name. Will that be a problem ?
Thanks again,
raju
-----Original Message-----
From: Max Cooper [mailto:[EMAIL PROTECTED]
Sent: Friday, April 04, 2003 3:11 AM
To: Struts Users Mailing List
Subject: Re: How to do authentication in different way for different
action classes
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
