You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Marsh-Bourdon, Christopher" <Ch...@DrKW.com> on 2005/05/12 11:42:21 UTC
RE: is it posible to pass a parameter to an action in configurati on
time?
<action path="..."
type="..."
name="..."
scope="request"
validate="false"
parameter="{parameter}">
<forward name="success" path="..." redirect="false" />
</action>
Use the parameter="{parameter}", you can then pick this up in the action
using:
String parameter = mapping.getParameter();
Cheers
Christopher Marsh-Bourdon
www.marsh-bourdon.com
-----Original Message-----
From: Rodolfo García Esteban/CYII [mailto:rgarciaesteban@cyii.es]
Sent: 12 May 2005 10:37
To: user@struts.apache.org
Subject: is it posible to pass a parameter to an action in configuration
time?
Hi,
I need to pass an url to an action for do some validations, this action is a parameter of application's configuration, the user mustn't modify it and it has the same value all the time. I don't know the best way to do this.
Thanks
________________________
Rodolfo
_______________________
--------------------------------------------------------------------------------
The information contained herein is confidential and is intended solely for the
addressee. Access by any other party is unauthorised without the express
written permission of the sender. If you are not the intended recipient, please
contact the sender either via the company switchboard on +44 (0)20 7623 8000, or
via e-mail return. If you have received this e-mail in error or wish to read our
e-mail disclaimer statement and monitoring policy, please refer to
http://www.drkw.com/disc/email/ or contact the sender. 3166
--------------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Best practice for redirecting on session timeout?
Posted by James Mitchell <jm...@apache.org>.
It really has nothing to do with caching, that meta refresh tag forces the
browser to refresh the page from the server (without JavaScript) so (for
example) the user returns from a long lunch and sees the browser sitting at
the login screen instead of the last customer search.
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
----- Original Message -----
From: "Aladin Alaily" <st...@aladin.ca>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Thursday, May 12, 2005 11:12 AM
Subject: Re: Best practice for redirecting on session timeout?
> Hi
>
>>> 1) Maintainability: if you want to change the timeout to 30 minutes (and
>>> you have 50 jsp pages), then you have to make the change 50 times.
>> Umm..ya...that's why I explicity said "preferrably via an include or let
>> a
>> filter do it for you".
>
> Missed the filter part :)
>
>>> 2) Business Logic: This approach will never prevent you Action from
>>> executing. Since you have to go through an action to reach the jsp
>>> page,
>>> when the *page* reloads, you are actually reloading the action first.
>> You must be confused here. The refresh happens ON the client after 20
>> minutes of inactivity. "Inactivity" being defined as "the browser has no
>> interaction with the server".
>
> Confused? Maybe... but what if the page is not cached on the client-side.
> Where is the browser going to get it from? ;)
>
>> After rereading the original post, it seems that I misunderstood the
>> original question. My proposed solution assumes you've already dealt
>> with
>> handling the expired session, so for all intents and purposes, we
>> actually
>> agree (in a 1/42 kind of way ;)
>
> At least we agree on something :)
>
> Aladin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Best practice for redirecting on session timeout?
Posted by Aladin Alaily <st...@aladin.ca>.
Hi
>> 1) Maintainability: if you want to change the timeout to 30 minutes (and
>> you have 50 jsp pages), then you have to make the change 50 times.
> Umm..ya...that's why I explicity said "preferrably via an include or let a
> filter do it for you".
Missed the filter part :)
>> 2) Business Logic: This approach will never prevent you Action from
>> executing. Since you have to go through an action to reach the jsp
>> page,
>> when the *page* reloads, you are actually reloading the action first.
> You must be confused here. The refresh happens ON the client after 20
> minutes of inactivity. "Inactivity" being defined as "the browser has no
> interaction with the server".
Confused? Maybe... but what if the page is not cached on the client-side.
Where is the browser going to get it from? ;)
> After rereading the original post, it seems that I misunderstood the
> original question. My proposed solution assumes you've already dealt with
> handling the expired session, so for all intents and purposes, we actually
> agree (in a 1/42 kind of way ;)
At least we agree on something :)
Aladin
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Best practice for redirecting on session timeout?
Posted by James Mitchell <jm...@apache.org>.
----- Original Message -----
From: <st...@aladin.ca>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Thursday, May 12, 2005 10:34 AM
Subject: Re: Best practice for redirecting on session timeout?
> Although this approach might work, I don't like it so much. The reasons:
>
> 1) Maintainability: if you want to change the timeout to 30 minutes (and
> you have 50 jsp pages), then you have to make the change 50 times.
Umm..ya...that's why I explicity said "preferrably via an include or let a
filter do it for you".
>
> 2) Business Logic: This approach will never prevent you Action from
> executing. Since you have to go through an action to reach the jsp page,
> when the *page* reloads, you are actually reloading the action first.
Actually, no, that's not at all what I said.
> Having said that, if your action does something that should only be
> executed if your session has not expired, your approach will not work.
You must be confused here. The refresh happens ON the client after 20
minutes of inactivity. "Inactivity" being defined as "the browser has no
interaction with the server".
The solution I offer is a way to "force" the browser to hit the server
(after the specified time has passed), which the server can then deal with
(the expired session).
>
> A combination of using a filter & session-config (in web.xml) solves both
> problems above. How?
>
> 1) You only have to change the session timeout setting in one place.
>
> 2) Your filter is executed before anything else. Hence, you never have to
> worry about an action being executed unintentionally.
>
> Aladin
>
That's correct, (sort of) but that's really only 1 of 42 ways to solve this
problem. What you presume by your above statements is that someone has
coded their app with a flat implementation of actions (e.g. no base
actions). This is considered to be a bad practice. You will always want a
single point of entry into your peice of the controller. You do this easily
with BaseActions. Besides reuse, you can solve the above situation quite
easily.
After rereading the original post, it seems that I misunderstood the
original question. My proposed solution assumes you've already dealt with
handling the expired session, so for all intents and purposes, we actually
agree (in a 1/42 kind of way ;)
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Best practice for redirecting on session timeout?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Good point Aladin...
However, I would take this a step further...
in pre-1.3 Struts, you might not want to implement your own RP for various
reasons, so I would suggest doing this in a filter instead... Same benefit
as modifying the RP, but doesn't touch Struts code and is also more
portable... should you ever want to not use Struts for some reason, you
don't have to worry about re-implementing your auth check.
In 1.3, you could probably make a good argument for modifying the RP
chain, certainly that's what your meant to be able to do!, but I think the
same good reasons for using a filter would still apply there.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Thu, May 12, 2005 10:57 am, struts@aladin.ca said:
> Hi,
>
> This approach would work as well. I just think that if you're going to do
> this in struts, it's better to do it in the RequestProcessor. Why?
> Assume that you are using the forward action defined in struts. If my
> session has timedout and I click on a link that uses the forward action, I
> will still see the page. This is because your BaseAction is never called.
> On the other hand, if you had checked the request in the
> RequestProcessor, I would have been blocked. This is because *ALL*
> actions pass through the RequestProcessor... even the struts-defined ones.
>
> That's the approach I would use (RequestProcessor approach) if my
> container didn't support filters.
>
> Aladin
>
>
>
>
>> I have a method in my BaseAction called "boolean checkAuth(request)".
>> then
>> in every Action I write I code this at the top
>>
>> // Check if session is active, if not redirect to login page
>> if( !checkAuth( request )){
>> log.info("*** Session has timed out ***");
>> errors.add( ActionErrors.GLOBAL_ERROR, new ActionError("
>> error.expired.session") );
>> saveErrors(request, errors);
>> return
>> (mapping.findForward(ApplicationConstants.APP_FORWARD_INVALID_SESSION));
>>
>> }
>>
>> seems to work fine.
>>
>> On 5/12/05, struts@aladin.ca <st...@aladin.ca> wrote:
>>>
>>> Although this approach might work, I don't like it so much. The
>>> reasons:
>>>
>>> 1) Maintainability: if you want to change the timeout to 30 minutes
>>> (and
>>> you have 50 jsp pages), then you have to make the change 50 times.
>>>
>>> 2) Business Logic: This approach will never prevent you Action from
>>> executing. Since you have to go through an action to reach the jsp
>>> page,
>>> when the *page* reloads, you are actually reloading the action first.
>>> Having said that, if your action does something that should only be
>>> executed if your session has not expired, your approach will not work.
>>>
>>> A combination of using a filter & session-config (in web.xml) solves
>>> both
>>> problems above. How?
>>>
>>> 1) You only have to change the session timeout setting in one place.
>>>
>>> 2) Your filter is executed before anything else. Hence, you never have
>>> to
>>> worry about an action being executed unintentionally.
>>>
>>> Aladin
>>>
>>>
>>> > That's easy, just drop this in all of your JSPs (preferrably via an
>>> > include
>>> > or let a filter do it for you).
>>> >
>>> > (assuming your session timeout is 20 minutes)
>>> >
>>> > <meta http-equiv="refresh" content="1200;/">
>>> >
>>> > You should be handling invalid/expired session state in your
>>> application
>>> > and
>>> > by using the above technique, it will work universally, whether you
>>> are
>>> > managing sessions from your actions, CMS, or some other service
>>> outside
>>> of
>>> > the conatiner, such as a product like SiteMinder by Netegrity.
>>> >
>>> > This will _force_ the browser to do a refresh of the page after 1200
>>> > seconds
>>> > (20 minutes), which will allow your app to handle the request (from a
>>> now
>>> > expired session) the same as it would if the user had initiated the
>>> > request
>>> > giving a hint of being on a rich client where such events are easily
>>> > handled.
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > James Mitchell
>>> > Software Engineer / Open Source Evangelist
>>> > Consulting / Mentoring / Freelance
>>> > EdgeTech, Inc.
>>> > http://www.edgetechservices.net/
>>> > 678.910.8017
>>> > AIM: jmitchtx
>>> > Yahoo: jmitchtx
>>> > MSN: jmitchell@apache.org
>>> >
>>> >
>>> >
>>> >
>>> > ----- Original Message -----
>>> > From: "Adam Lipscombe" <ad...@expensys.com>
>>> > To: "'Struts Users Mailing List'" <us...@struts.apache.org>
>>> > Sent: Thursday, May 12, 2005 6:19 AM
>>> > Subject: Best practice for redirecting on session timeout?
>>> >
>>> >
>>> >> Folks,
>>> >>
>>> >>
>>> >> I there a standard way of handling session timeouts. If a user has
>>> been
>>> >> inactive for longer than N minutes I want to redirect them to the
>>> login
>>> >> page.
>>> >>
>>> >> It occurs to me that this could be done in a) the RequestProcessor
>>> or
>>> b)
>>> >> in
>>> >> an JSP include.
>>> >>
>>> >>
>>> >> Is there another way?
>>> >> What is best practice?
>>> >>
>>> >>
>>> >> TIA - Adam
>>> >>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> >> For additional commands, e-mail: user-help@struts.apache.org
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> > For additional commands, e-mail: user-help@struts.apache.org
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>
>>
>> --
>> -Dave
>> ChaChaNY@Gmail.com
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Best practice for redirecting on session timeout?[Scanned]
Posted by Rick Reumann <st...@reumann.net>.
Getting ready to leave so don't have time to look at your code but my
doFilter looks like...
//doFilter ...
String path = request.getRequestURL().toString();
String contextPath = request.getContextPath();
if (pathNeedsCheck(path)) {
HttpSession session = request.getSession(false);
if (session == null) {
response.sendRedirect(contextPath+"/sessionTimeOut.jsp");
return;
}
}
private boolean pathNeedsCheck(String path) {
//returns true if none of these paths found
boolean needsCheck = path.indexOf("/index.jsp") == -1 &&
path.indexOf("/logout.jsp") == -1 && path.indexOf("/entry") == -1 &&
path.indexOf("/sessionTimeOut.jsp") == -1;
return needsCheck;
}
I'm sure there are much better ways than hardcoding the paths like I did
above that I didn't want the session time out to check, but the above
works at least.
It's also nice to include what James said to force the browser to
refresh that equals your session time out time, so that, like he said,
when the user comes back from a long lunch they are brought to the
session timed out page, vs thinking they can click on something and then
being brought to the session timed out page. Just more graceful in my
opinion to add this. Usually your session time out page could just be
the login page with a message there about how you have timed out.. bla
bla blah.
Adam Lipscombe wrote the following on 5/13/2005 6:19 AM:
> Folks
>
>
> Many thanks for all your input on this. I decided to go with the filter
> approach.
> My doFilter() method is below. I certainly traps the timeout.
>
> The problem now is that the redirect fails no matter if I use
> "/pages/SessionTimedOut.jsp" or a fully qualified URL (e.g
> "http://localhost:8080/ExpenSysWT/pages/SessionTimedOut.jsp")
>
>
> The error message that is logged is: "failed to set redirect, msg = null"
>
>
> Any help much appreciated
>
>
> TIA -Adam
>
>
>
>
>
>
> ----------------------
>
> public void doFilter(ServletRequest request,
> ServletResponse response,
> FilterChain chain)
> {
> HttpServletRequest httpServletRequest = (HttpServletRequest) request;
> HttpServletResponse httpServletResponse = (HttpServletResponse)
> response;
> HttpSession httpSession = httpServletRequest.getSession();
>
> boolean sessionTimedOut = false;
>
> try
> {
> if (false == httpServletRequest.isRequestedSessionIdValid())
> {
> sessionTimedOut = true;
> }
> else
> {
> String requestedAction = httpServletRequest.getRequestURI();
> if (false == requestedAction.endsWith(StrutsConstants.LOGIN_ACTION))
> {
> if (null != httpSession)
> {
> if (null == httpSession.getAttribute(Constants.SESSION_CONTEXT))
> {
> sessionTimedOut = true;
> }
> }
> }
> }
>
> if (true == sessionTimedOut)
> {
> logger.warning("session timed out");
> httpServletResponse.sendRedirect("/pages/SessionTimedOut.jsp");
> }
>
> chain.doFilter(request, response);
>
> }
> catch (Exception ex)
> {
> String msg = "failed to set redirect, msg = " + ex.getMessage();
> logger.severe(msg);
> }
> }
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: Best practice for redirecting on session timeout?[Scanned]
Posted by Adam Lipscombe <ad...@expensys.com>.
Folks
Many thanks for all your input on this. I decided to go with the filter
approach.
My doFilter() method is below. I certainly traps the timeout.
The problem now is that the redirect fails no matter if I use
"/pages/SessionTimedOut.jsp" or a fully qualified URL (e.g
"http://localhost:8080/ExpenSysWT/pages/SessionTimedOut.jsp")
The error message that is logged is: "failed to set redirect, msg = null"
Any help much appreciated
TIA -Adam
----------------------
public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain chain)
{
HttpServletRequest httpServletRequest = (HttpServletRequest) request;
HttpServletResponse httpServletResponse = (HttpServletResponse)
response;
HttpSession httpSession = httpServletRequest.getSession();
boolean sessionTimedOut = false;
try
{
if (false == httpServletRequest.isRequestedSessionIdValid())
{
sessionTimedOut = true;
}
else
{
String requestedAction = httpServletRequest.getRequestURI();
if (false == requestedAction.endsWith(StrutsConstants.LOGIN_ACTION))
{
if (null != httpSession)
{
if (null == httpSession.getAttribute(Constants.SESSION_CONTEXT))
{
sessionTimedOut = true;
}
}
}
}
if (true == sessionTimedOut)
{
logger.warning("session timed out");
httpServletResponse.sendRedirect("/pages/SessionTimedOut.jsp");
}
chain.doFilter(request, response);
}
catch (Exception ex)
{
String msg = "failed to set redirect, msg = " + ex.getMessage();
logger.severe(msg);
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Best practice for redirecting on session timeout?[Scanned]
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Sorry, I lost track of the thread (stupid webmail interface!)... can you
outline your method again?
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Thu, May 12, 2005 1:39 pm, David Johnson said:
> So, how what would you all say about my method? does this seem to be a
> valid
> method for controlling this?
>
> On 5/12/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
>>
>> Good point Aladin...
>>
>> However, I would take this a step further...
>>
>> in pre-1.3 Struts, you might not want to implement your own RP for
>> various
>> reasons, so I would suggest doing this in a filter instead... Same
>> benefit
>> as modifying the RP, but doesn't touch Struts code and is also more
>> portable... should you ever want to not use Struts for some reason, you
>> don't have to worry about re-implementing your auth check.
>>
>> In 1.3, you could probably make a good argument for modifying the RP
>> chain, certainly that's what your meant to be able to do!, but I think
>> the
>> same good reasons for using a filter would still apply there.
>>
>> --
>> Frank W. Zammetti
>> Founder and Chief Software Architect
>> Omnytex Technologies
>> http://www.omnytex.com
>>
>> On Thu, May 12, 2005 10:57 am, struts@aladin.ca said:
>> > Hi,
>> >
>> > This approach would work as well. I just think that if you're going to
>> do
>> > this in struts, it's better to do it in the RequestProcessor. Why?
>> > Assume that you are using the forward action defined in struts. If my
>> > session has timedout and I click on a link that uses the forward
>> action,
>> I
>> > will still see the page. This is because your BaseAction is never
>> called.
>> > On the other hand, if you had checked the request in the
>> > RequestProcessor, I would have been blocked. This is because *ALL*
>> > actions pass through the RequestProcessor... even the struts-defined
>> ones.
>> >
>> > That's the approach I would use (RequestProcessor approach) if my
>> > container didn't support filters.
>> >
>> > Aladin
>> >
>> >
>> >
>> >
>> >> I have a method in my BaseAction called "boolean checkAuth(request)".
>> >> then
>> >> in every Action I write I code this at the top
>> >>
>> >> // Check if session is active, if not redirect to login page
>> >> if( !checkAuth( request )){
>> >> log.info("*** Session has timed out ***");
>> >> errors.add( ActionErrors.GLOBAL_ERROR, new ActionError("
>> >> error.expired.session") );
>> >> saveErrors(request, errors);
>> >> return
>> >> (mapping.findForward(ApplicationConstants.APP_FORWARD_INVALID_SESSION
>> ));
>> >>
>> >> }
>> >>
>> >> seems to work fine.
>> >>
>> >> On 5/12/05, struts@aladin.ca <st...@aladin.ca> wrote:
>> >>>
>> >>> Although this approach might work, I don't like it so much. The
>> >>> reasons:
>> >>>
>> >>> 1) Maintainability: if you want to change the timeout to 30 minutes
>> >>> (and
>> >>> you have 50 jsp pages), then you have to make the change 50 times.
>> >>>
>> >>> 2) Business Logic: This approach will never prevent you Action from
>> >>> executing. Since you have to go through an action to reach the jsp
>> >>> page,
>> >>> when the *page* reloads, you are actually reloading the action
>> first.
>> >>> Having said that, if your action does something that should only be
>> >>> executed if your session has not expired, your approach will not
>> work.
>> >>>
>> >>> A combination of using a filter & session-config (in web.xml) solves
>> >>> both
>> >>> problems above. How?
>> >>>
>> >>> 1) You only have to change the session timeout setting in one place.
>> >>>
>> >>> 2) Your filter is executed before anything else. Hence, you never
>> have
>> >>> to
>> >>> worry about an action being executed unintentionally.
>> >>>
>> >>> Aladin
>> >>>
>> >>>
>> >>> > That's easy, just drop this in all of your JSPs (preferrably via
>> an
>> >>> > include
>> >>> > or let a filter do it for you).
>> >>> >
>> >>> > (assuming your session timeout is 20 minutes)
>> >>> >
>> >>> > <meta http-equiv="refresh" content="1200;/">
>> >>> >
>> >>> > You should be handling invalid/expired session state in your
>> >>> application
>> >>> > and
>> >>> > by using the above technique, it will work universally, whether
>> you
>> >>> are
>> >>> > managing sessions from your actions, CMS, or some other service
>> >>> outside
>> >>> of
>> >>> > the conatiner, such as a product like SiteMinder by Netegrity.
>> >>> >
>> >>> > This will _force_ the browser to do a refresh of the page after
>> 1200
>> >>> > seconds
>> >>> > (20 minutes), which will allow your app to handle the request
>> (from
>> a
>> >>> now
>> >>> > expired session) the same as it would if the user had initiated
>> the
>> >>> > request
>> >>> > giving a hint of being on a rich client where such events are
>> easily
>> >>> > handled.
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > James Mitchell
>> >>> > Software Engineer / Open Source Evangelist
>> >>> > Consulting / Mentoring / Freelance
>> >>> > EdgeTech, Inc.
>> >>> > http://www.edgetechservices.net/
>> >>> > 678.910.8017
>> >>> > AIM: jmitchtx
>> >>> > Yahoo: jmitchtx
>> >>> > MSN: jmitchell@apache.org
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > ----- Original Message -----
>> >>> > From: "Adam Lipscombe" <ad...@expensys.com>
>> >>> > To: "'Struts Users Mailing List'" <us...@struts.apache.org>
>> >>> > Sent: Thursday, May 12, 2005 6:19 AM
>> >>> > Subject: Best practice for redirecting on session timeout?
>> >>> >
>> >>> >
>> >>> >> Folks,
>> >>> >>
>> >>> >>
>> >>> >> I there a standard way of handling session timeouts. If a user
>> has
>> >>> been
>> >>> >> inactive for longer than N minutes I want to redirect them to the
>> >>> login
>> >>> >> page.
>> >>> >>
>> >>> >> It occurs to me that this could be done in a) the
>> RequestProcessor
>> >>> or
>> >>> b)
>> >>> >> in
>> >>> >> an JSP include.
>> >>> >>
>> >>> >>
>> >>> >> Is there another way?
>> >>> >> What is best practice?
>> >>> >>
>> >>> >>
>> >>> >> TIA - Adam
>> >>> >>
>> >>> >>
>> >>> >>
>> ---------------------------------------------------------------------
>> >>> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> >>> >> For additional commands, e-mail: user-help@struts.apache.org
>> >>> >>
>> >>> >>
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> ---------------------------------------------------------------------
>> >>> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> >>> > For additional commands, e-mail: user-help@struts.apache.org
>> >>> >
>> >>> >
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> >>> For additional commands, e-mail: user-help@struts.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> -Dave
>> >> ChaChaNY@Gmail.com
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: user-help@struts.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
> --
> -Dave
> ChaChaNY@Gmail.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Best practice for redirecting on session timeout?[Scanned]
Posted by David Johnson <ch...@gmail.com>.
So, how what would you all say about my method? does this seem to be a valid
method for controlling this?
On 5/12/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
> Good point Aladin...
>
> However, I would take this a step further...
>
> in pre-1.3 Struts, you might not want to implement your own RP for various
> reasons, so I would suggest doing this in a filter instead... Same benefit
> as modifying the RP, but doesn't touch Struts code and is also more
> portable... should you ever want to not use Struts for some reason, you
> don't have to worry about re-implementing your auth check.
>
> In 1.3, you could probably make a good argument for modifying the RP
> chain, certainly that's what your meant to be able to do!, but I think the
> same good reasons for using a filter would still apply there.
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> On Thu, May 12, 2005 10:57 am, struts@aladin.ca said:
> > Hi,
> >
> > This approach would work as well. I just think that if you're going to
> do
> > this in struts, it's better to do it in the RequestProcessor. Why?
> > Assume that you are using the forward action defined in struts. If my
> > session has timedout and I click on a link that uses the forward action,
> I
> > will still see the page. This is because your BaseAction is never
> called.
> > On the other hand, if you had checked the request in the
> > RequestProcessor, I would have been blocked. This is because *ALL*
> > actions pass through the RequestProcessor... even the struts-defined
> ones.
> >
> > That's the approach I would use (RequestProcessor approach) if my
> > container didn't support filters.
> >
> > Aladin
> >
> >
> >
> >
> >> I have a method in my BaseAction called "boolean checkAuth(request)".
> >> then
> >> in every Action I write I code this at the top
> >>
> >> // Check if session is active, if not redirect to login page
> >> if( !checkAuth( request )){
> >> log.info("*** Session has timed out ***");
> >> errors.add( ActionErrors.GLOBAL_ERROR, new ActionError("
> >> error.expired.session") );
> >> saveErrors(request, errors);
> >> return
> >> (mapping.findForward(ApplicationConstants.APP_FORWARD_INVALID_SESSION
> ));
> >>
> >> }
> >>
> >> seems to work fine.
> >>
> >> On 5/12/05, struts@aladin.ca <st...@aladin.ca> wrote:
> >>>
> >>> Although this approach might work, I don't like it so much. The
> >>> reasons:
> >>>
> >>> 1) Maintainability: if you want to change the timeout to 30 minutes
> >>> (and
> >>> you have 50 jsp pages), then you have to make the change 50 times.
> >>>
> >>> 2) Business Logic: This approach will never prevent you Action from
> >>> executing. Since you have to go through an action to reach the jsp
> >>> page,
> >>> when the *page* reloads, you are actually reloading the action first.
> >>> Having said that, if your action does something that should only be
> >>> executed if your session has not expired, your approach will not work.
> >>>
> >>> A combination of using a filter & session-config (in web.xml) solves
> >>> both
> >>> problems above. How?
> >>>
> >>> 1) You only have to change the session timeout setting in one place.
> >>>
> >>> 2) Your filter is executed before anything else. Hence, you never have
> >>> to
> >>> worry about an action being executed unintentionally.
> >>>
> >>> Aladin
> >>>
> >>>
> >>> > That's easy, just drop this in all of your JSPs (preferrably via an
> >>> > include
> >>> > or let a filter do it for you).
> >>> >
> >>> > (assuming your session timeout is 20 minutes)
> >>> >
> >>> > <meta http-equiv="refresh" content="1200;/">
> >>> >
> >>> > You should be handling invalid/expired session state in your
> >>> application
> >>> > and
> >>> > by using the above technique, it will work universally, whether you
> >>> are
> >>> > managing sessions from your actions, CMS, or some other service
> >>> outside
> >>> of
> >>> > the conatiner, such as a product like SiteMinder by Netegrity.
> >>> >
> >>> > This will _force_ the browser to do a refresh of the page after 1200
> >>> > seconds
> >>> > (20 minutes), which will allow your app to handle the request (from
> a
> >>> now
> >>> > expired session) the same as it would if the user had initiated the
> >>> > request
> >>> > giving a hint of being on a rich client where such events are easily
> >>> > handled.
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > James Mitchell
> >>> > Software Engineer / Open Source Evangelist
> >>> > Consulting / Mentoring / Freelance
> >>> > EdgeTech, Inc.
> >>> > http://www.edgetechservices.net/
> >>> > 678.910.8017
> >>> > AIM: jmitchtx
> >>> > Yahoo: jmitchtx
> >>> > MSN: jmitchell@apache.org
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > ----- Original Message -----
> >>> > From: "Adam Lipscombe" <ad...@expensys.com>
> >>> > To: "'Struts Users Mailing List'" <us...@struts.apache.org>
> >>> > Sent: Thursday, May 12, 2005 6:19 AM
> >>> > Subject: Best practice for redirecting on session timeout?
> >>> >
> >>> >
> >>> >> Folks,
> >>> >>
> >>> >>
> >>> >> I there a standard way of handling session timeouts. If a user has
> >>> been
> >>> >> inactive for longer than N minutes I want to redirect them to the
> >>> login
> >>> >> page.
> >>> >>
> >>> >> It occurs to me that this could be done in a) the RequestProcessor
> >>> or
> >>> b)
> >>> >> in
> >>> >> an JSP include.
> >>> >>
> >>> >>
> >>> >> Is there another way?
> >>> >> What is best practice?
> >>> >>
> >>> >>
> >>> >> TIA - Adam
> >>> >>
> >>> >>
> >>> >>
> ---------------------------------------------------------------------
> >>> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >>> >> For additional commands, e-mail: user-help@struts.apache.org
> >>> >>
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> >
> ---------------------------------------------------------------------
> >>> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >>> > For additional commands, e-mail: user-help@struts.apache.org
> >>> >
> >>> >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >>> For additional commands, e-mail: user-help@struts.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> -Dave
> >> ChaChaNY@Gmail.com
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
-Dave
ChaChaNY@Gmail.com
Re: Best practice for redirecting on session timeout?
Posted by st...@aladin.ca.
Hi,
This approach would work as well. I just think that if you're going to do
this in struts, it's better to do it in the RequestProcessor. Why?
Assume that you are using the forward action defined in struts. If my
session has timedout and I click on a link that uses the forward action, I
will still see the page. This is because your BaseAction is never called.
On the other hand, if you had checked the request in the
RequestProcessor, I would have been blocked. This is because *ALL*
actions pass through the RequestProcessor... even the struts-defined ones.
That's the approach I would use (RequestProcessor approach) if my
container didn't support filters.
Aladin
> I have a method in my BaseAction called "boolean checkAuth(request)". then
> in every Action I write I code this at the top
>
> // Check if session is active, if not redirect to login page
> if( !checkAuth( request )){
> log.info("*** Session has timed out ***");
> errors.add( ActionErrors.GLOBAL_ERROR, new ActionError("
> error.expired.session") );
> saveErrors(request, errors);
> return
> (mapping.findForward(ApplicationConstants.APP_FORWARD_INVALID_SESSION));
>
> }
>
> seems to work fine.
>
> On 5/12/05, struts@aladin.ca <st...@aladin.ca> wrote:
>>
>> Although this approach might work, I don't like it so much. The reasons:
>>
>> 1) Maintainability: if you want to change the timeout to 30 minutes (and
>> you have 50 jsp pages), then you have to make the change 50 times.
>>
>> 2) Business Logic: This approach will never prevent you Action from
>> executing. Since you have to go through an action to reach the jsp page,
>> when the *page* reloads, you are actually reloading the action first.
>> Having said that, if your action does something that should only be
>> executed if your session has not expired, your approach will not work.
>>
>> A combination of using a filter & session-config (in web.xml) solves
>> both
>> problems above. How?
>>
>> 1) You only have to change the session timeout setting in one place.
>>
>> 2) Your filter is executed before anything else. Hence, you never have
>> to
>> worry about an action being executed unintentionally.
>>
>> Aladin
>>
>>
>> > That's easy, just drop this in all of your JSPs (preferrably via an
>> > include
>> > or let a filter do it for you).
>> >
>> > (assuming your session timeout is 20 minutes)
>> >
>> > <meta http-equiv="refresh" content="1200;/">
>> >
>> > You should be handling invalid/expired session state in your
>> application
>> > and
>> > by using the above technique, it will work universally, whether you
>> are
>> > managing sessions from your actions, CMS, or some other service
>> outside
>> of
>> > the conatiner, such as a product like SiteMinder by Netegrity.
>> >
>> > This will _force_ the browser to do a refresh of the page after 1200
>> > seconds
>> > (20 minutes), which will allow your app to handle the request (from a
>> now
>> > expired session) the same as it would if the user had initiated the
>> > request
>> > giving a hint of being on a rich client where such events are easily
>> > handled.
>> >
>> >
>> >
>> >
>> > --
>> > James Mitchell
>> > Software Engineer / Open Source Evangelist
>> > Consulting / Mentoring / Freelance
>> > EdgeTech, Inc.
>> > http://www.edgetechservices.net/
>> > 678.910.8017
>> > AIM: jmitchtx
>> > Yahoo: jmitchtx
>> > MSN: jmitchell@apache.org
>> >
>> >
>> >
>> >
>> > ----- Original Message -----
>> > From: "Adam Lipscombe" <ad...@expensys.com>
>> > To: "'Struts Users Mailing List'" <us...@struts.apache.org>
>> > Sent: Thursday, May 12, 2005 6:19 AM
>> > Subject: Best practice for redirecting on session timeout?
>> >
>> >
>> >> Folks,
>> >>
>> >>
>> >> I there a standard way of handling session timeouts. If a user has
>> been
>> >> inactive for longer than N minutes I want to redirect them to the
>> login
>> >> page.
>> >>
>> >> It occurs to me that this could be done in a) the RequestProcessor or
>> b)
>> >> in
>> >> an JSP include.
>> >>
>> >>
>> >> Is there another way?
>> >> What is best practice?
>> >>
>> >>
>> >> TIA - Adam
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: user-help@struts.apache.org
>> >>
>> >>
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: user-help@struts.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
> --
> -Dave
> ChaChaNY@Gmail.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Best practice for redirecting on session timeout?
Posted by David Johnson <ch...@gmail.com>.
I have a method in my BaseAction called "boolean checkAuth(request)". then
in every Action I write I code this at the top
// Check if session is active, if not redirect to login page
if( !checkAuth( request )){
log.info("*** Session has timed out ***");
errors.add( ActionErrors.GLOBAL_ERROR, new ActionError("
error.expired.session") );
saveErrors(request, errors);
return (mapping.findForward(ApplicationConstants.APP_FORWARD_INVALID_SESSION));
}
seems to work fine.
On 5/12/05, struts@aladin.ca <st...@aladin.ca> wrote:
>
> Although this approach might work, I don't like it so much. The reasons:
>
> 1) Maintainability: if you want to change the timeout to 30 minutes (and
> you have 50 jsp pages), then you have to make the change 50 times.
>
> 2) Business Logic: This approach will never prevent you Action from
> executing. Since you have to go through an action to reach the jsp page,
> when the *page* reloads, you are actually reloading the action first.
> Having said that, if your action does something that should only be
> executed if your session has not expired, your approach will not work.
>
> A combination of using a filter & session-config (in web.xml) solves both
> problems above. How?
>
> 1) You only have to change the session timeout setting in one place.
>
> 2) Your filter is executed before anything else. Hence, you never have to
> worry about an action being executed unintentionally.
>
> Aladin
>
>
> > That's easy, just drop this in all of your JSPs (preferrably via an
> > include
> > or let a filter do it for you).
> >
> > (assuming your session timeout is 20 minutes)
> >
> > <meta http-equiv="refresh" content="1200;/">
> >
> > You should be handling invalid/expired session state in your application
> > and
> > by using the above technique, it will work universally, whether you are
> > managing sessions from your actions, CMS, or some other service outside
> of
> > the conatiner, such as a product like SiteMinder by Netegrity.
> >
> > This will _force_ the browser to do a refresh of the page after 1200
> > seconds
> > (20 minutes), which will allow your app to handle the request (from a
> now
> > expired session) the same as it would if the user had initiated the
> > request
> > giving a hint of being on a rich client where such events are easily
> > handled.
> >
> >
> >
> >
> > --
> > James Mitchell
> > Software Engineer / Open Source Evangelist
> > Consulting / Mentoring / Freelance
> > EdgeTech, Inc.
> > http://www.edgetechservices.net/
> > 678.910.8017
> > AIM: jmitchtx
> > Yahoo: jmitchtx
> > MSN: jmitchell@apache.org
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "Adam Lipscombe" <ad...@expensys.com>
> > To: "'Struts Users Mailing List'" <us...@struts.apache.org>
> > Sent: Thursday, May 12, 2005 6:19 AM
> > Subject: Best practice for redirecting on session timeout?
> >
> >
> >> Folks,
> >>
> >>
> >> I there a standard way of handling session timeouts. If a user has been
> >> inactive for longer than N minutes I want to redirect them to the login
> >> page.
> >>
> >> It occurs to me that this could be done in a) the RequestProcessor or
> b)
> >> in
> >> an JSP include.
> >>
> >>
> >> Is there another way?
> >> What is best practice?
> >>
> >>
> >> TIA - Adam
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
-Dave
ChaChaNY@Gmail.com
Re: Best practice for redirecting on session timeout?
Posted by st...@aladin.ca.
Although this approach might work, I don't like it so much. The reasons:
1) Maintainability: if you want to change the timeout to 30 minutes (and
you have 50 jsp pages), then you have to make the change 50 times.
2) Business Logic: This approach will never prevent you Action from
executing. Since you have to go through an action to reach the jsp page,
when the *page* reloads, you are actually reloading the action first.
Having said that, if your action does something that should only be
executed if your session has not expired, your approach will not work.
A combination of using a filter & session-config (in web.xml) solves both
problems above. How?
1) You only have to change the session timeout setting in one place.
2) Your filter is executed before anything else. Hence, you never have to
worry about an action being executed unintentionally.
Aladin
> That's easy, just drop this in all of your JSPs (preferrably via an
> include
> or let a filter do it for you).
>
> (assuming your session timeout is 20 minutes)
>
> <meta http-equiv="refresh" content="1200;/">
>
> You should be handling invalid/expired session state in your application
> and
> by using the above technique, it will work universally, whether you are
> managing sessions from your actions, CMS, or some other service outside of
> the conatiner, such as a product like SiteMinder by Netegrity.
>
> This will _force_ the browser to do a refresh of the page after 1200
> seconds
> (20 minutes), which will allow your app to handle the request (from a now
> expired session) the same as it would if the user had initiated the
> request
> giving a hint of being on a rich client where such events are easily
> handled.
>
>
>
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> Consulting / Mentoring / Freelance
> EdgeTech, Inc.
> http://www.edgetechservices.net/
> 678.910.8017
> AIM: jmitchtx
> Yahoo: jmitchtx
> MSN: jmitchell@apache.org
>
>
>
>
> ----- Original Message -----
> From: "Adam Lipscombe" <ad...@expensys.com>
> To: "'Struts Users Mailing List'" <us...@struts.apache.org>
> Sent: Thursday, May 12, 2005 6:19 AM
> Subject: Best practice for redirecting on session timeout?
>
>
>> Folks,
>>
>>
>> I there a standard way of handling session timeouts. If a user has been
>> inactive for longer than N minutes I want to redirect them to the login
>> page.
>>
>> It occurs to me that this could be done in a) the RequestProcessor or b)
>> in
>> an JSP include.
>>
>>
>> Is there another way?
>> What is best practice?
>>
>>
>> TIA - Adam
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Best practice for redirecting on session timeout?
Posted by James Mitchell <jm...@apache.org>.
That's easy, just drop this in all of your JSPs (preferrably via an include
or let a filter do it for you).
(assuming your session timeout is 20 minutes)
<meta http-equiv="refresh" content="1200;/">
You should be handling invalid/expired session state in your application and
by using the above technique, it will work universally, whether you are
managing sessions from your actions, CMS, or some other service outside of
the conatiner, such as a product like SiteMinder by Netegrity.
This will _force_ the browser to do a refresh of the page after 1200 seconds
(20 minutes), which will allow your app to handle the request (from a now
expired session) the same as it would if the user had initiated the request
giving a hint of being on a rich client where such events are easily
handled.
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
----- Original Message -----
From: "Adam Lipscombe" <ad...@expensys.com>
To: "'Struts Users Mailing List'" <us...@struts.apache.org>
Sent: Thursday, May 12, 2005 6:19 AM
Subject: Best practice for redirecting on session timeout?
> Folks,
>
>
> I there a standard way of handling session timeouts. If a user has been
> inactive for longer than N minutes I want to redirect them to the login
> page.
>
> It occurs to me that this could be done in a) the RequestProcessor or b)
> in
> an JSP include.
>
>
> Is there another way?
> What is best practice?
>
>
> TIA - Adam
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Best practice for redirecting on session timeout?
Posted by Shailender Jain <sh...@teleatlas.com>.
Hello,
It should be done in the RequestProcessor.
If none of your JSP is doing a forward to other JSP directly.
Shailender Jain
Adam Lipscombe wrote:
> Folks,
>
> I there a standard way of handling session timeouts. If a user has been
> inactive for longer than N minutes I want to redirect them to the login
> page.
>
> It occurs to me that this could be done in a) the RequestProcessor or b) in
> an JSP include.
>
> Is there another way?
> What is best practice?
>
> TIA - Adam
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Best practice for redirecting on session timeout?
Posted by Aladin Alaily <st...@aladin.ca>.
Hi Adam,
One possibility is to have the timing out of the session be managed by
your container and have the redirection issued by a filter.
If you are using Tomcat 4+ this is very straightforward to implement.
In the web.xml, you declare your session-timeout value and your filter
class. After having declared your filter, you need to map it to a uri
for which it will be applied.
Aladin
Adam Lipscombe wrote:
> Folks,
>
>
> I there a standard way of handling session timeouts. If a user has been
> inactive for longer than N minutes I want to redirect them to the login
> page.
>
> It occurs to me that this could be done in a) the RequestProcessor or b) in
> an JSP include.
>
>
> Is there another way?
> What is best practice?
>
>
> TIA - Adam
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Best practice for redirecting on session timeout?
Posted by Adam Lipscombe <ad...@expensys.com>.
Folks,
I there a standard way of handling session timeouts. If a user has been
inactive for longer than N minutes I want to redirect them to the login
page.
It occurs to me that this could be done in a) the RequestProcessor or b) in
an JSP include.
Is there another way?
What is best practice?
TIA - Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org