struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Cooper" <...@maxcooper.com>
Subject Re: [OT] - Realm Security - How to set overlapping constraints?
Date Mon, 07 Jul 2003 14:26:42 GMT
----- Original Message ----- 
From: "Navjot Singh" <navjot.s@net4india.net>
> 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:craigmcc@apache.org]
> |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 <navjot.s@net4india.net>
> |> Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> |> To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> |> 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: struts-user-unsubscribe@jakarta.apache.org
> |For additional commands, e-mail: struts-user-help@jakarta.apache.org
> |
> |
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message