Thanks Craig,

Reversing the order of constraints does work. I should have RTFM.

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

If i move my role constraints to struts-config, think i can handle that in
my actions then. Am i right?

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]

Reply via email to