struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jing Zhou" <j...@netspread.com>
Subject Re: Looking for ideas for action servlet checking for logged in user.
Date Wed, 25 Jun 2003 16:53:38 GMT
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" <Michael.Remijan@solocup.com>
To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
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:jing@netspread.com]
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" <ahardy.struts@cyberspaceroad.com>
To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
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" <Larry.Zappeterrini@SanchezProjects.com>
> > To: "'Struts Users Mailing List'" <struts-user@jakarta.apache.org>
> > 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: henrik.bentel@teradyne.com [mailto:henrik.bentel@teradyne.com]
> >>Sent: Tuesday, June 24, 2003 4:59 PM
> >>To: struts-user@jakarta.apache.org
> >>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: struts-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >>
> >>
> >>
> >
> >
***************************************************************************
> >
> >>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: 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
>
>


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