http://securityfilter.sourceforge.net/
This emulates the container managed security but uses filters.
You can define the security contraints in security-filter.xml (looks similar in structure to web.xml) eg
<security-constraint>
<web-resource-collection>
<web-resource-name>Administrator-only Area</web-resource-name>
<url-pattern>/admin/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>You can even use the Tomcat's JDBC Realm with it. This means you can use the request.isUserInRole() and you can define access to Struts actions by role eg:
<action
path="/admin/Admin"
type="org.apache.struts.actions.ForwardAction"
parameter=".main.admin"
roles="admin,someOtherRole,yetAnotherRole">
</action>Or display tiles if they have the right role eg
<definition name=".secrets.tile" path="/WEB-INF/jsp/tiles/secrets.jsp" role="admin" />
The other problem you normally encounter is creating a few objects that you want in your session after a user logs in eg get user's name, email, phone number etc throw it into a User object and store it in the session so you can refer to it later.
There are a couple of choices...
1. Create a BaseAction class that all of your other Actions extend 2. Use a Filter
The process is the same for each:
a. Check to see if request.getUserPrincipal() is not null. If null, the user has not been authenticated
b. If the user has been authenticated check to see if you have defined a session variable eg session.getAttribute("USER_LOGGED_IN")
c. If it hasn't been defined, then this is a newly logged in user and you can do your initialisation stuff, record the login etc and store something in our session variable session.setAttribute("USER_LOGGED_IN", Obj)
If you want to log the user out you can use session.invalidate()
--jason
Adam Hardy wrote:
The drawback to using filters compared to security constraints is that you would have to roll your own login mechanism - which seems unnecessary when you could use the container's authentication method.
Did you mention having to change Tomcat to get it to use your JDBC realm? I'm not sure quite what you mean, but yes I suppose if you have a complex realm module and you're not going to use container-managed security, I guess filters or constraints would be just as good.
Adam
Michael Remijan wrote:
Filters have mapping patterns just like servlets have mapping patters (take a look at the web.xml DTD). So like you say servlet "Foo" is mapped to *.foo or /foo/* you can map a filter to urls as well. So if you have a directory in your webapp named "secure". can protect all the jsp pages in that directory with the mapping /secure/*. similarly, you can add the mappings of servlets to protect them in the same way.
Michael.
-----Original Message----- From: Jing Zhou [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2003 11:54 AM To: Struts Users Mailing List Subject: Re: Looking for ideas for action servlet checking for logged in user.
This is an interesting use of Filters. Our action mappings have an attribute, 'privileged'. When the privileged attribute is set to true, users only with a true privileged mode in his/her action tracking (in the user's session) can execute the corresponding actions.
Can a filter be easily bound to the dynamic security requirements as shown above? and in what ways, any ideas?
Jing
----- Original Message ----- From: "Michael Remijan" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, June 25, 2003 10:49 AM
Subject: RE: Looking for ideas for action servlet checking for logged in
user.
I've found using security constraints to be a little cumbersome, especially
since it requires some moderate modification of tomcat to put in a jdbc
realm that fits your needs.
My preference is to use Filters. A filter set up on your secure directory
(specifed as /secure-dir-name/*) can be run, check for an object in the
session, and easily redirect if not found.
Mike
-----Original Message----- From: Jing Zhou [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2003 10:10 AM To: Struts Users Mailing List Subject: Re: Looking for ideas for action servlet checking for logged in user.
----- Original Message ----- From: "Adam Hardy" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, June 25, 2003 4:13 AM
Subject: Re: Looking for ideas for action servlet checking for logged in
user.
I would use container-managed security. All the secured pages should go in a directory which is the target of a security constraint in the deployment descriptor. This forces the user to log in when trying to access any secured pages. In the actions where a user-object is required, this can be retrieved on demand using the user-name from the login, and then stored in the session.
What I am doing is, yes, everything is under security constraints and when
the user logins, an action tracking object is created to maintain the user
related objects. The action tracking is stored in the user's session. When
the user logout, the action tracking is cleared and removed from the
user's session. The action tracking has a lot other responsibilities.
hth Adam
Jing
Jing Zhou wrote:
----- Original Message ----- From: "Larry Zappeterrini" <[EMAIL PROTECTED]>
To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Tuesday, June 24, 2003 4:13 PM
Subject: RE: Looking for ideas for action servlet checking for logged in
user.
Check out http://marc.theaimsgroup.com/?t=104454850300003&r=1&w=2 for a
possible solution.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 4:59 PM To: [EMAIL PROTECTED] Subject: Looking for ideas for action servlet checking for logged in user.
I have a webapp which have several pages which require the user to be
logged in(have a httpSession with a "usercontainer" object stored) , and
a
few pages that doesn't require a log in(the log-in page, references, indexes...). All pages are fronted by actions. My current solution is to check for valid login in every action class
that
needs to protect its invocation. That seems tedious. I though about
extending the action servlet to do it, but then it would check for all
requests.
And I do want to distinguish between if the user is
authorized(isUSerInRole) and if he/she is even logged in, so I can't use
the role parameter in the action element.
My next idea is extending the action servlet pluss adding parameters
that
can go into the action element in the struts-config.xml file.
(some thing like <action path="/doImportantAction" type="my.actionClass"
usersession="true"> )
This would require my action servlet to know about my userContainer
stored
***************************************************************************in the httpsession. Pluss modifying the struts-config file.
I haven't looked into how hard this is, figure I'd ask someone who's run
into this before.
Any other good approaches, or should I just stick with what I got?(check
individually in every action)
Yes. So far so good. One possible improvement is that you put all of the checking codes into a base class of your action classes. Then you extend the action mapping to provide additional attributes that allow the checking codes to configure themselves dynamically for the corresponding actions, e.g. the usersession attribute.
thanks, Henrik Bentel
Jing
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
This electronic mail transmission contains confidential and/or
privileged
information intended only for the person(s) named. Any use,
distribution,
***************************************************************************copying or disclosure by another person is strictly prohibited.
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- 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]
-- Jason Lea
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
