+1 on Paul's comments. Doing this with the RequestProcessor is putting a relatively minor detail into the core of your application. Filters are good. I also think attaching a User.java object to your HttpSession is a very good idea. I actually have a number of things I like to attach with the user's personal data, so I attach a StateContainer.java for the user. But the idea is the same.
Jack On 4/14/05, Paul McCulloch <[EMAIL PROTECTED]> wrote: > 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] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
