When the login requirement isn't met, it raises an exception which is globally configured to bounce to a globally-configured login forward.
I now realize that deferring the login check to the action has a hole in it:
I keep the logged-innes in the session in the form of a property within a user container, which gets cleaned up on session timeout; it implements HttpSessionBindingListener.
Hitting any action after a timeout does indeed bounce the user to a login, using the above mechanism in the base action.
However, if a form which was presented prior to session timeout is posted *after* a timeout, its validation is processed prior to the action being called, and any errors are presented back to the user.
In my case, the input page for those forms have chrome (implemented using Tiles) which relies on the user container, which has since been cleaned out, but my action hasn't had a chance to intercede and bounce to the login. So, the view gets called w/o the supporting user information. :-(
I appears that I ought to be extending the RequestProcessor check login state instead. I'd like a way to be able to declaratively ( in the config ) express which actions require a login and have the RequestProcessor subclass enforce this in the same manner as my base action is now doing it - raising an exception which is globaly configured to forward to the login.
Any thoughts on the best way to go about this? Particularly, how can I get the per-action login requirement setting into the RequestProcessor. I'm already using the 'parameter' on many actions for something else, btw.
This question seems to have been typically answered with the suggestion to use the method I have been using ( base action subclass ) or a servlet filter. I'd prefer not to use a servlet filter because I want to continue using the struts global-exception/global-forward.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
