----- Original Message ----- From: "Navjot Singh" <[EMAIL PROTECTED]> > Thanks Craig, > > Reversing the order of constraints does work. I should have RTFM.
That kind of surprises me. The Servlet Spec v2.3 section SRV 11.1 says that exact patterns should be tried first, then paths (longest to shortest, by number of elements), then extensions, then the default servlet (/). The description of each of these types of patterns is also in the spec (the rules are simple and clear). Going by the spec, I would think that it would try /p/status.do first, since it is an exact pattern, and it would fail (403 error) there if the user didn't have the admin role. Perhaps there is something going on since the servlet mapping pattern is *.do. Craig, any input on what is going on there? > > But now, there is another problem. > When "user" is authenticated once, and then i accessed a resource that needs > login to "admin". It simply throws 403. That is the correct behavior -- your user should log out and then back in if they need to change who they are along the way. I like to shoot for designing the system so that each user needs only one account to do everything they need to do, but sometimes that can be a real challenge as requirements are added on. Some folks have a hard time with the roles concept (that one user can have multiple roles), too, which complicates things. > Can't it throw LOGIN PAGE? I can replace the default 403 page with my LOGIN > page but i guess that wouldn't be the right solution. That won't work with container-managed security -- the container typically won't accept login form submittals when it (the server) didn't send the user to the login page. Setting the 403 error page to the login page, or having your app send the user there does not count (the server won't like the submittal in those cases). > > If i move my role constraints to struts-config, think i can handle that in > my actions then. Am i right? Struts will just give an error if a user doesn't have the required role to access an action, which doesn't really help in your situation. Doing programmatic security in the action itself won't help, either. The basic problem is that you can't send the user to the login page yourself and expect the container-managed security to go along with it. The user needs to log out if they need to change accounts while using the app. You could have a message on the 403 error page that suggests the user log out if they need to change what user they are logged in as. It isn't ideal, but it might be your only alternative. -Max > > regards > Navjot Singh > > > |-----Original Message----- > |From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] > |Sent: Saturday, July 05, 2003 11:37 PM > |To: Struts Users Mailing List > |Subject: Re: [OT] - Realm Security - How to set overlapping constraints? > | > |On Sat, 5 Jul 2003, Navjot Singh wrote: > | > |> Date: Sat, 5 Jul 2003 21:39:34 +0530 > |> From: Navjot Singh <[EMAIL PROTECTED]> > |> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > |> To: Struts Users Mailing List <[EMAIL PROTECTED]> > |> Subject: [OT] - Realm Security - How to set overlapping constraints? > |> > |> hi, > |> > |> It may be quite simple but it's not working for me. > |> > |> I have a set of servlets > |> /myapp/p/ab.do > |> /myapp/p/groups.do > |> /myapp/p/contacts.do > |> > |> AND I want all of them to be accessible to roles "user" and "admin". > |> > |> There is 1 more servlet that MUST be accessible ONLY to "admin" > |> /myapp/p/status.do > |> > |> I am setting config like given below. > |> But still, "user" roles are being able to access status.do > |> > |> What am i doing wrong? > |> > |> thanks for any help > |> -navjot singh > |> > |> __My XML Declarations__ > |> > |> <security-constraint> > |> <web-resource-collection> > |> <web-resource-name>Protected</web-resource-name> > |> <url-pattern>*.do</url-pattern> > |> <http-method>GET</http-method> > |> <http-method>POST</http-method> > |> </web-resource-collection> > |> <auth-constraint> > |> <role-name>user</role-name> > |> <role-name>admin</role-name> > |> </auth-constraint> > |> </security-constraint> > | > |The list of security roles inside an <auth-constraint> is an *or* list, so > |the container is doing exactly what you told it to do -- allow anyone with > |either "user" or "admin" to access all "*.do" URLs. > | > |> > |> <security-constraint> > |> <web-resource-collection> > |> <web-resource-name>Show Status</web-resource-name> > |> <url-pattern>/p/status.do</url-pattern> > |> <http-method>GET</http-method> > |> <http-method>POST</http-method> > |> </web-resource-collection> > |> <auth-constraint> > |> <role-name>admin</role-name> > |> </auth-constraint> > |> </security-constraint> > |> > | > |The fact that this one is second means that it will never get used, > |because "/p/status.do" satisfies the matching pattern on the first test. > |Try reversing your constraints. > | > |Another alternative is to do some of the role-based protection on Struts > |actions in struts-config.xml instead, by using the "role" attribute on the > |<action> element. That way, you can have just your first constraint above > |(the one matching "*.do") to force people to log on, and then do fine > |grained control at the Struts level. > | > |> <security-role> > |> <role-name>admin</role-name> > |> </security-role> > |> > |> <security-role> > |> <role-name>user</role-name> > |> </security-role> > |> > | > |Craig > | > |--------------------------------------------------------------------- > |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]
