Well, since it won't be protected under any of the other url-patterns, you
could simply remove this 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>
What server are you using? I am pretty sure we used a security-constraint
with no roles associated with it to allow public access (no authentication
required) on one of the projects I worked on with WebLogic 5.10 at one
point. The spec is not crystal clear about how that should work, so it is
possible that different servers have implemented it differently. I am not
sure about this, but I wonder if some servers assume that even
unathenticated users are in some 'everybody' or 'guest' group. If that is
the case (and I am not sure if it is), you might be able to require that
role for the items you want to be public.
Some/all servers require that you list out the roles that are relevant for
your application in the web.xml with sections like this:
<security-role>
<description>arole</description>
<role-name>arole</role-name>
</security-role>
Then when you specify <role-name>*<role-name>, I think it will try all the
roles listed in web.xml to see if the user has any of them. Your users will
need to have one of the roles to be able to access the protected resources.
But the removing the security-constraint above should take care of your
current issue.
Hope that helps,
-Max
----- Original Message -----
From: "Rajendra Kadam" <[EMAIL PROTECTED]>
To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Friday, April 04, 2003 11:08 AM
Subject: RE: How to do authentication in different way for different action
classes
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
