You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Michael <mi...@idtect.com> on 2002/08/21 12:24:38 UTC
Specifying roles for actions
I just got J2EE container managed security working and now I'd like to
add roles to my struts action. I downloaded the Struts 1.1b2 and have
it installed. When I add a role to my action:
<!-- Process a user logon -->
<action path="/login"
type="com.idtect.oemserver.web.LoginAction"
name="loginForm"
scope="request"
input="/login.jsp"
roles="idtect_readonly">
I get the following error:
HTTP Status 400 - User is not authorized to access action /login
I was expecting it to display a login box. So then I protected a JSP
using the web.xml file and accessed the JSP (getting the login box and
logging in). I retried my action and got the same error. This puzzled
me because I was already logged in.
I know this is a new feature, but if anyone has any examples or a link
to some documentation on this I'd greatly appreciate. The thought of
specifying security for each action in my web.xml really bothers me. I
think this roles attribute is a great addition to Struts.
Michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: RE : Specifying roles for actions
Posted by Eddie Bush <ek...@swbell.net>.
Why would your login action have a role associated with it?! ... isn't
executing that action where you determine the role? I ... think ...
that might be your problem. See - until a person is authenticated there
is no prinicpal. Until you have a principal, you don't have the
associated role information loaded. Until you have the associated roles
loaded, you can't very well use it as criteria ...
Maybe I missed something in earlier banter on this topic.
Regards,
Eddie
Michael wrote:
>>You will most likely want to use a <security-constraint> and an
>><auth-method> in your web.xml file if you want the container to
>>authenticate users automatically. The "roles" attribute in
>>struts-config.xml lets you impose additional restrictions above and
>>
>beyond
>
>>whatever is set up in web.xml, but doesn't have any way to trigger
>>authentication in the first place.
>>
>
>I do in fact have this in my web.xml file. In fact for the test1.jsp
>it's working properly. So after this I add the "roles" to the action
>but the action gives me the error..
>
>Web.xml
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Test 1</web-resource-name>
> <url-pattern>/test1.jsp</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> <auth-constraint>
> <role-name>idtect_readonly</role-name>
> </auth-constraint>
> </security-constraint>
> <login-config>
> <auth-method>BASIC</auth-method>
> <realm-name>Idtect OEM Server</realm-name>
> </login-config>
>
> <security-role>
> <role-name>idtect_readonly</role-name>
> </security-role>
>
>Struts_config.xml
>
><!-- Process a user logon -->
><action path="/login"
> type="com.idtect.oemserver.web.LoginAction"
> name="loginForm"
> scope="request"
> input="/login.jsp"
> roles="idtect_readonly">>
>
>I get the following error:
>
>HTTP Status 400 - User is not authorized to access action /login
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Specifying roles for actions
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 22 Aug 2002, Max Cooper wrote:
> The only problem here is keeping the POSTed parameters, if the original
> request was a POST. This either requires special handling in Struts (to make
> them available to the Action, but not any non-Actions you might forward to,
> like a JSP) or a filter to make the posted parameters available to all
> resources in the request. Perhaps there is an opportunity for synergy
> between Struts and the SecurityFilter project here.
FYI, this particular issue was the hardest thing about implementing form
based login in Tomcat.
The nice thing about using a Filter to implement application-managed
security (the way that SecurityFilter does it) is you don't have to modify
Struts, or your Struts-based application, to use it. Just put them
together and configure them both. On the other hand, there's no reason to
limit the availability of SecurityFilter to only those users smart enough
to adopt Struts :-) -- it is generally useful.
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Specifying roles for actions
Posted by Max Cooper <ma...@maxcooper.com>.
Michael,
I am glad you got it working.
> > I am not sure how much value the roles attribute for an
> > action has if it can't invoke the authentication sequence
> > (i.e. send you to the login page, and get you back to your
> > original request). It seems you would have to duplicate the
>
> I assumed Struts would in fact do this. If it doesn't then I don't see
> how this feature can even be useful. I definitely don't want my user to
> get an error message when they try to access the site. Can someone
> confirm if Struts can provide this functionality (sending the user to a
> login page and then returning them to the original action requested)?
I think Struts might be able to do something tricky, but it probably isn't
worth the headache. I can imagine a sequence like this:
Scenario #1: not authorized
1. Request for action comes in, but the authenticated user does not meet the
role requirement.
2. Struts sets the 403 error code and returns, letting the container show
the 403 error page.
(it might do this already, but it seems weird that you got a 400 error page
that said "not authorized", so I am not sure)
Scenario #2: not authenticated
1. Request for action comes in, but the user is not authenticated.
2. Struts remembers the action requested and redirects to a special secured
URL.
3. The container sees that you aren't authenticated to access the special
secured URL and sends you to the login form.
4. You sumbit a login form, and get redirected to the special secured URL.
5. The response from the special secured URL is a redirect to the action you
originally requested.
6. Your request for the original action succeeds now that you are
authenticated and meet the role requirement.
The only problem here is keeping the POSTed parameters, if the original
request was a POST. This either requires special handling in Struts (to make
them available to the Action, but not any non-Actions you might forward to,
like a JSP) or a filter to make the posted parameters available to all
resources in the request. Perhaps there is an opportunity for synergy
between Struts and the SecurityFilter project here.
>
> > Also, watch out for specifying http-methods in web.xml, as
> > the settings won't match if the request is using a different
> > method. This might be okay if you want to ONLY allow GETs and
> > POSTs and block access to everything else with another
>
> You lost me. What else is there besides GET & POST? We're doing a
> basic webapp, HTML browser based.
Those are the two most important/common ones, but there are a bunch more
(OPTIONS, HEAD, PUT, DELETE, TRACE, CONNECT). Your actions will only respond
to GET and POST (is this right, listers?), so this probably isn't a major
issue. I suggest not specifying the http-method for your circumstances (so
the security-constraint will match all requests for the patterns, regardless
of the method), but like I said it probably isn't a major concern either
way. I wouldn't worry about it, but you might benefit from the opportunity
to reduce the bulk of your web.xml file.
-Max
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE : Specifying roles for actions
Posted by Michael <mi...@idtect.com>.
> You might need to make the request for /login.do (rather than
> simply /login) depending on how your ActionServlet is mapped.
You were right on the money! I changed the form to post to login.do and
now it works, but only if I'm already authenticated! If I haven't
already authenticated, then I get the same error as before (400 - User
is not authorized to access action /login). Which takes me to your next
point:
> I am not sure how much value the roles attribute for an
> action has if it can't invoke the authentication sequence
> (i.e. send you to the login page, and get you back to your
> original request). It seems you would have to duplicate the
I assumed Struts would in fact do this. If it doesn't then I don't see
how this feature can even be useful. I definitely don't want my user to
get an error message when they try to access the site. Can someone
confirm if Struts can provide this functionality (sending the user to a
login page and then returning them to the original action requested)?
> Also, watch out for specifying http-methods in web.xml, as
> the settings won't match if the request is using a different
> method. This might be okay if you want to ONLY allow GETs and
> POSTs and block access to everything else with another
You lost me. What else is there besides GET & POST? We're doing a
basic webapp, HTML browser based.
Thanks for the help,
Michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Proposal for struts-humor
Posted by Ted Husted <hu...@apache.org>.
The current advice is to set your mailreader to segregate the subject
lines containing [FRIDAY] or [BEER]. I'm tempted to add these
instructions to the Struts home page.
In practice, subdividing lists rarely works since people with questions
usually can't tell where to post them.
In this case, the [*] gang is looking for an audience and wouldn't be
happy with a smaller venue.
-Ted.
Michael wrote:
> I'd like to propose a new mailing list called struts-humor that way I
> won't risk missing any of the important mails that get lost in with the
> technical struts discussion.
>
> Michael
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
Ted Husted, Husted dot Com, Fairport NY US
co-author, Java Web Development with Struts
Order it today:
<http://husted.com/struts/book.html>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Proposal for struts-humor
Posted by Eddie Bush <ek...@swbell.net>.
Obviously you haven't followed the list closely for long ;-) This was
proposed and shot down. Add a filter to your email client.
Regards,
Eddie
Michael wrote:
>I'd like to propose a new mailing list called struts-humor that way I
>won't risk missing any of the important mails that get lost in with the
>technical struts discussion.
>
>Michael
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Proposal for struts-humor
Posted by Michael <mi...@idtect.com>.
I'd like to propose a new mailing list called struts-humor that way I
won't risk missing any of the important mails that get lost in with the
technical struts discussion.
Michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: RE : Specifying roles for actions
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 23 Aug 2002, Michael wrote:
> Date: Fri, 23 Aug 2002 09:30:48 +0200
> From: Michael <mi...@idtect.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: 'Struts Users Mailing List' <st...@jakarta.apache.org>
> Subject: RE : Specifying roles for actions
>
> > FYI, this particular issue was the hardest thing about implementing
> form
> > based login in Tomcat.
>
> > The nice thing about using a Filter to implement application-managed
> > security (the way that SecurityFilter does it) is you don't have to
> modify
> > Struts, or your Struts-based application, to use it. Just put them
> > together and configure them both. On the other hand, there's no
> reason to
> > limit the availability of SecurityFilter to only those users smart
> enough
> > to adopt Struts :-) -- it is generally useful.
>
> But Craig, do you have any ideas about how Struts can redirect a user to
> the login page? For now do you recommend not assigning roles to actions
> in the struts_config.xml?
>
Redirecting to the login page isn't legal -- the container will use it on
the first request for a protected resource from an unauthenticated user,
and then the container will complete the original request.
If you're confused about the flow, switch your app to BASIC authentication
temporarily, and you will see how it works. There's no such thing as
forwarding to the login page, right? Form based login works exactly the
same way.
> Michael
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE : Specifying roles for actions
Posted by Michael <mi...@idtect.com>.
> FYI, this particular issue was the hardest thing about implementing
form
> based login in Tomcat.
> The nice thing about using a Filter to implement application-managed
> security (the way that SecurityFilter does it) is you don't have to
modify
> Struts, or your Struts-based application, to use it. Just put them
> together and configure them both. On the other hand, there's no
reason to
> limit the availability of SecurityFilter to only those users smart
enough
> to adopt Struts :-) -- it is generally useful.
But Craig, do you have any ideas about how Struts can redirect a user to
the login page? For now do you recommend not assigning roles to actions
in the struts_config.xml?
Michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Specifying roles for actions
Posted by Max Cooper <ma...@maxcooper.com>.
Michael,
Have you tried accessing /test1.jsp first to get authenticated?
The 400 error indicates that the resource was not found. 403 is the error
code for "not authorized". I have noticed that you can get 400 errors if
there is a FileNotFoundException thrown while handling the request, even if
the request mapped to a "real" resource like a Struts action.
You might need to make the request for /login.do (rather than simply /login)
depending on how your ActionServlet is mapped.
I am not sure how much value the roles attribute for an action has if it
can't invoke the authentication sequence (i.e. send you to the login page,
and get you back to your original request). It seems you would have to
duplicate the settings with url-mappings in web.xml to get the just-in-time
authentication that you probably want. At that point, there doesn't seem to
be any reason to duplicate the role requirement in struts-config.xml (and
the downside that you would have to maintain the information in two places).
On the other hand, it might be useful to specify the roles in
struts-config.xml because it is easier for the action implementor to specify
them there. If you had a script that would then read the struts-config.xml
to produce matching settings in web.xml, it might be of value.
Also, watch out for specifying http-methods in web.xml, as the settings
won't match if the request is using a different method. This might be okay
if you want to ONLY allow GETs and POSTs and block access to everything else
with another security-constraint like this:
<security-constraint>
<web-resource-collection>
<web-resource-name>Block all requests not specifically granted by
other constraints</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name></role-name>
</auth-constraint>
</security-constraint>
Watch out, though, as this "no access" constraint will be matched before any
"extension mappings" like *.do or *.jsp. Exact patterns like /test1.jsp and
longer path patterns like /auth/* will be evaluated first, however.
-Max
----- Original Message -----
From: "Michael" <mi...@idtect.com>
To: "'Struts Users Mailing List'" <st...@jakarta.apache.org>
Sent: Thursday, August 22, 2002 12:58 AM
Subject: RE : Specifying roles for actions
> > You will most likely want to use a <security-constraint> and an
> > <auth-method> in your web.xml file if you want the container to
> > authenticate users automatically. The "roles" attribute in
> > struts-config.xml lets you impose additional restrictions above and
> beyond
> > whatever is set up in web.xml, but doesn't have any way to trigger
> > authentication in the first place.
>
> I do in fact have this in my web.xml file. In fact for the test1.jsp
> it's working properly. So after this I add the "roles" to the action
> but the action gives me the error..
>
> Web.xml
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Test 1</web-resource-name>
> <url-pattern>/test1.jsp</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> <auth-constraint>
> <role-name>idtect_readonly</role-name>
> </auth-constraint>
> </security-constraint>
> <login-config>
> <auth-method>BASIC</auth-method>
> <realm-name>Idtect OEM Server</realm-name>
> </login-config>
>
> <security-role>
> <role-name>idtect_readonly</role-name>
> </security-role>
>
> Struts_config.xml
>
> <!-- Process a user logon -->
> <action path="/login"
> type="com.idtect.oemserver.web.LoginAction"
> name="loginForm"
> scope="request"
> input="/login.jsp"
> roles="idtect_readonly">>
>
> I get the following error:
>
> HTTP Status 400 - User is not authorized to access action /login
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE : Specifying roles for actions
Posted by Michael <mi...@idtect.com>.
> You will most likely want to use a <security-constraint> and an
> <auth-method> in your web.xml file if you want the container to
> authenticate users automatically. The "roles" attribute in
> struts-config.xml lets you impose additional restrictions above and
beyond
> whatever is set up in web.xml, but doesn't have any way to trigger
> authentication in the first place.
I do in fact have this in my web.xml file. In fact for the test1.jsp
it's working properly. So after this I add the "roles" to the action
but the action gives me the error..
Web.xml
<security-constraint>
<web-resource-collection>
<web-resource-name>Test 1</web-resource-name>
<url-pattern>/test1.jsp</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>idtect_readonly</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>Idtect OEM Server</realm-name>
</login-config>
<security-role>
<role-name>idtect_readonly</role-name>
</security-role>
Struts_config.xml
<!-- Process a user logon -->
<action path="/login"
type="com.idtect.oemserver.web.LoginAction"
name="loginForm"
scope="request"
input="/login.jsp"
roles="idtect_readonly">>
I get the following error:
HTTP Status 400 - User is not authorized to access action /login
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Specifying roles for actions
Posted by "Craig R. McClanahan" <cr...@apache.org>.
You will most likely want to use a <security-constraint> and an
<auth-method> in your web.xml file if you want the container to
authenticate users automatically. The "roles" attribute in
struts-config.xml lets you impose additional restrictions above and beyond
whatever is set up in web.xml, but doesn't have any way to trigger
authentication in the first place.
Craig
On Wed, 21 Aug 2002, Michael wrote:
> Date: Wed, 21 Aug 2002 12:24:38 +0200
> From: Michael <mi...@idtect.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: Specifying roles for actions
>
> I just got J2EE container managed security working and now I'd like to
> add roles to my struts action. I downloaded the Struts 1.1b2 and have
> it installed. When I add a role to my action:
>
> <!-- Process a user logon -->
> <action path="/login"
> type="com.idtect.oemserver.web.LoginAction"
> name="loginForm"
> scope="request"
> input="/login.jsp"
> roles="idtect_readonly">
>
> I get the following error:
>
> HTTP Status 400 - User is not authorized to access action /login
>
> I was expecting it to display a login box. So then I protected a JSP
> using the web.xml file and accessed the JSP (getting the login box and
> logging in). I retried my action and got the same error. This puzzled
> me because I was already logged in.
>
> I know this is a new feature, but if anyone has any examples or a link
> to some documentation on this I'd greatly appreciate. The thought of
> specifying security for each action in my web.xml really bothers me. I
> think this roles attribute is a great addition to Struts.
>
> Michael
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>