You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by David Johnson <ch...@gmail.com> on 2005/05/12 19:39:39 UTC
Re: Best practice for redirecting on session timeout?[Scanned]
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?[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