Hi Scott,
Firstly - changing the subject breaks the threading in many mailreaders!
Securing your application is completely independant of Struts. Neither needs
to know anything about the other - that is why it is such a nice & easy
solution.
Yes - I'm implying exactly what you say I am.
Here's the pseudocode for the filter:
doFilter(...){
if(request.getSession().getAttribute("user" == null)){
//Not authenticated - send all non login request to the
login page
if(request.getServletPath().equals("the login url")){
filterChain.doFilter(..);
}else{
response.sendRedirect("the login page");
}
}else{
//user is authenticated - send the request on it's way
filterChain.doFilter(..)
}
}
That's it.
Paul
> -----Original Message-----
> From: Scott Purcell [mailto:[EMAIL PROTECTED]
> Sent: 2005/14/04 16:03
> To: Struts Users Mailing List
> Subject: Session now with Filter
>
>
> Thank you very much for your comments on this topic Paul.
>
> Now, I understand the basics of using a filter, extending the
> base class and configuration in the web.xml file. But how can
> I use a filter in unison with Struts.
>
> I am not seeing how I would use the filter. Are you implying
> that I should possibly use the filter to check for the
> existance of the session and "user" object? And if the
> session does not exist? use a redirect to the login page? So
> this filter would only look at incoming requests?
>
> Thanks,
> Scott
>
>
>
>
>
> -----Original Message-----
> From: Paul McCulloch [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 14, 2005 9:33 AM
> To: 'Struts Users Mailing List'
> Subject: RE: Handling Session Expiration Properly
>
>
> Hi Scott,
>
> I can't remeber if it was your question I replied to regarding
> authentication where I recommended using a filter to do this,
> rather than
> modifying the request processor. If it wasn't your question then I'd
> recommend a serach of the archives. If it was you - I still
> think modifying
> the request processor is not the best solution!
>
> Anyway - some comments on the solution you are working with...
>
> I suggest that you only create the user object and attach it
> to the session
> object when the user successfully logs in. The presence of a
> user object in
> session tells your application that there is a valid user -
> and who the user
> is.
>
> If the user's session expires then the next request they make
> will be for a
> new session (with no user) - so they will be sent to the login page.
>
> There is no need to change the signature of your base action. The user
> object is in session which can be obtained from the existing paramater
> "request" - there is no need to explicitly pass the user around.
>
> Changing the base action to manage security throws up some
> other pottential
> problems. If you start to use another action variant, such as
> DispatchAction, you won't have any security. If you really
> don't want to use
> Filters then I suggest that you modify the request processor
> to check that
> the user is logged in before calling your action, and send
> them to the login
> page if they aren't
>
> Seriously though - a filter is far easier (& web framework
> agnostic) way to
> handle this.
>
> HTH, and feel free to carry on beating this one...
>
> Paul
>
>
> > -----Original Message-----
> > From: Scott Purcell [mailto:[EMAIL PROTECTED]
> > Sent: 2005/14/04 15:04
> > To: user@struts.apache.org
> > Subject: Handling Session Expiration Properly
> >
> >
> > Hello,
> > I hope I have not beaten this to death on this list, but I
> > have never gotten an answer that has served my interest. So I
> > rethought the question and I am reposting it now.
> >
> > The application I created, is a web-app in which a login is
> > required of a "username" and "password". Pretty standard
> > stuff. I am not using container authentication, I am just
> > going to a database and pulling out data based upon the entries.
> >
> > The way I configured this, is I extended the
> > RequestProcessor, and each time a user hits the Controller, I
> > check if there is a "user" object in the session. If there is
> > great. If not I create a new one and set a logged in boolean
> > to false. Now if the user has successfully logged in, I set
> > the logged in boolean to true.
> >
> > This step is where I ran into problems. I checked the FAQ on
> > session expiration handling, and the FAQs recommended
> > extending a base action class and checking for the logged in
> > flag. If the flag was not set, then I would throw a global
> > exception, throw them to the front door with a ActionMessage
> > stating "session expired".
> >
> > Now don't get me wrong this works, but by extending the
> > Action class I kind of screwed myself by not being able to
> > use a RequestDispatcher because now the signature of the
> > "subclassed action" was not the same as what the
> > requestDispatcher is looking for. When I extended the Action,
> > I added a check for the user flag:
> > eg:
> > public ActionForward executeAction(ActionMapping mapping,
> > ActionForm form,
> > HttpServletRequest request,
> > HttpServletResponse response,
> > AppObject appObject,
> > UserObject user)
> > throws Exception {
> >
> >
> > So to sum this up, when I am in the RequestProcessor, is
> > there anyway to find the Action they are going to, so I can
> > do my check of logged in? I am looking at the method
> > signature and do not see anything but a request and response
> > object here.
> >
> > Or is there another method I should be extending to find out
> > where they are going? Because if I can see that they are
> > going to an inside page, and their flag is set to "not logged
> > in", then I can send them to the front door with a message
> > stating "session expired" and not send the message to people
> > who are just hitting the front login page.
> >
> > If this does not make sense, please email me back.
> >
> > Thanks for your time,
> > Scott
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> Axios Email Confidentiality Footer
> Privileged/Confidential Information may be contained in this
> message. If you are not the addressee indicated in this
> message (or responsible for delivery of the message to such
> person), you may not copy or deliver this message to anyone.
> In such case, you should destroy this message, and notify us
> immediately. If you or your employer does not consent to
> Internet email messages of this kind, please advise us
> immediately. Opinions, conclusions and other information
> expressed in this message are not given or endorsed by my
> Company or employer unless otherwise indicated by an
> authorised representative independent of this message.
>
> WARNING:
> While Axios Systems Ltd takes steps to prevent computer
> viruses from being transmitted via electronic mail
> attachments we cannot guarantee that attachments do not
> contain computer virus code. You are therefore strongly
> advised to undertake anti virus checks prior to accessing the
> attachment to this electronic mail. Axios Systems Ltd grants
> no warranties regarding performance use or quality of any
> attachment and undertakes no liability for loss or damage
> howsoever caused.
>
>
> ---------------------------------------------------------------------
> 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]
