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]
