Re: Session Timeout and "Direct Reference to login page"

2004-05-26 Thread Veniamin Fichin
Jonathan Eric Miller wrote:
The strange thing is that this page seems to only intermittently be
displayed. i.e. it is catching the case where the session expires, but, in
some cases since I'm using container based security, it is going back to the
login page. Sometimes it goes to this page first, and then brings up the
login page. Other times, it just goes straight to the login page. I need to
look into it further. I have SingleSignOn enabled, so, I'm not sure if that
   May be it's working so fast you sometimes don't notice this 
redirection, and sometimes do?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Session Timeout and "Direct Reference to login page"

2004-05-24 Thread Jonathan Eric Miller
I found out about a few other functions that make it bit easier. I think I
have it working using the following,

public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
if(((HttpServletRequest)request).getRequestedSessionId() != null &&
((HttpServletRequest)request).isRequestedSessionIdValid() == false) {
RequestDispatcher rd =
request.getRequestDispatcher("/WEB-INF/sessionexpired.jsp");
rd.forward(request, response);
}
else {
chain.doFilter(request, response);
}
}

The strange thing is that this page seems to only intermittently be
displayed. i.e. it is catching the case where the session expires, but, in
some cases since I'm using container based security, it is going back to the
login page. Sometimes it goes to this page first, and then brings up the
login page. Other times, it just goes straight to the login page. I need to
look into it further. I have SingleSignOn enabled, so, I'm not sure if that
might have something to do with it. I need to do more testing. In theory, I
think it should go to the login page each time. So, I'm thinking of putting
a check in my login page similar to the above that just shows optional text
stating that the session has expired.

Another thing that I'm wondering is if it is possible to use a servlet as
the login page for Tomcat rather than a .jsp file.

Jon

- Original Message - 
From: "Veniamin Fichin" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Friday, May 21, 2004 7:15 AM
Subject: Re: Session Timeout and "Direct Reference to login page"


> Jonathan Eric Miller wrote:
>
> > Yeah, that seems like it would work. I'm wondering if I could maybe use
a
> > filter by itself though and not use the listener and do something like
the
> > following.
> >
> > 1. Intercept all requests with a filter.
> > 2. Get the HttpSession out of the request. Get the session ID by calling
> > HttpSession.getId();
> > 3. Get the cookie array and see if there is a cookie named "jsessionid."
If
> > there is, compare the two session IDs. If they are different forward to
> > sessionexpired.jsp to display error page. Otherwise, continue as normal.
>
> I've just tried this way, it works. Look at example .java file in
> attach for example, it's Filter implementation. Thanks for the
> suggestion, it's very useful.
>
>



> -
> 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]



Re: Session Timeout and "Direct Reference to login page"

2004-05-21 Thread Veniamin Fichin
Jonathan Eric Miller wrote:
Yeah, that seems like it would work. I'm wondering if I could maybe use a
filter by itself though and not use the listener and do something like the
following.
1. Intercept all requests with a filter.
2. Get the HttpSession out of the request. Get the session ID by calling
HttpSession.getId();
3. Get the cookie array and see if there is a cookie named "jsessionid." If
there is, compare the two session IDs. If they are different forward to
sessionexpired.jsp to display error page. Otherwise, continue as normal.
   I've just tried this way, it works. Look at example .java file in 
attach for example, it's Filter implementation. Thanks for the 
suggestion, it's very useful.

package org.unchqua.test.servlet;

import java.io.IOException;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletOutputStream;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.Cookie;

public class NewSessionFilter implements Filter {

private FilterConfig fconf;

public void init(FilterConfig arg0) throws ServletException {
fconf=arg0;
}

public void doFilter(ServletRequest req, ServletResponse resp,
 FilterChain fchain) throws IOException, ServletException {
boolean newManualSession=false;
String fromSession=null;
if (((HttpServletRequest)req).getSession(false)!=null) {
fromSession=((HttpServletRequest)req).getSession(false).getId();
}
if (fromSession==null) {
fromSession=((HttpServletRequest)req).getSession().getId();
newManualSession=true;
}
String fromCookie=null;
Cookie[] cooks=((HttpServletRequest)req).getCookies();
if (cooks!=null) {
for (int i=0; i-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Session Timeout and "Direct Reference to login page"

2004-05-20 Thread Jonathan Eric Miller
Thanks for the suggestion. The reason that I can't do it that way (as far as
I know) is because I'm using container-based security. I'm not handling the
submission of the login form directly.

Before I switched to using container-based security, I was doing it exactly
as you described.

Jon

- Original Message - 
From: "Ben Souther" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Thursday, May 20, 2004 12:26 PM
Subject: Re: Session Timeout and "Direct Reference to login page"


> What was wrong with the first suggestion?
>
> 1.) When your user logs in, throw an object in their session.
> 2.) In each servlet/jsp (or, better, in a filter), test for the existence
of
> that object and forward back to the login if it is null.
>
> Seems pretty straight forward to me.
>
>
>
>
>
> On Thursday 20 May 2004 12:51 pm, Jonathan Eric Miller wrote:
> > Yeah, that seems like it would work. I'm wondering if I could maybe use
a
> > filter by itself though and not use the listener and do something like
the
> > following.
> >
> > 1. Intercept all requests with a filter.
> > 2. Get the HttpSession out of the request. Get the session ID by calling
> > HttpSession.getId();
> > 3. Get the cookie array and see if there is a cookie named "jsessionid."
If
> > there is, compare the two session IDs. If they are different forward to
> > sessionexpired.jsp to display error page. Otherwise, continue as normal.
> >
> > This assumes that the session ID changes everytime it expires. As far as
I
> > know, that is the case.
> >
> > I would also have to figure out how to get the jsessionid if it is in
the
> > URL rather than in a cookie.
> >
> > I would prefer to do it that way if I can for the sake of simplicity. I
> > want to avoid having a Hashtable that grows indefinitely if possible.
> >
> > Does it seem like this work, or, am I missing something?
> >
> > I'm wondering if this wouldn't work if I didn't have single sign-on
> > enabled. i.e. the login page would get displayed at session expiration.
I'm
> > not sure if the login page does only forwards, or if it does a redirect.
> > I'm thinking the redirect might make the above logic not work since the
> > session ID in the cookie would get updated first by the login page.
Note,
> > the filter runs after the login page.
> >
> > It seems like there should be a generic way to handle this kind of thing
> > that is well understood and known to work.
> >
> > Jon
> >
> > - Original Message -
> > From: "Veniamin Fichin" <[EMAIL PROTECTED]>
> > To: "Tomcat Users List" <[EMAIL PROTECTED]>
> > Sent: Thursday, May 20, 2004 2:59 AM
> > Subject: Re: Session Timeout and "Direct Reference to login page"
> >
> > > Jonathan Eric Miller wrote:
> > > > Thanks. I think option #1 is what I'm looking for. What I don't
> >
> > understand
> >
> > > > is what I need to do with the session listener though?
> > > >
> > > > I don't understand how to determine whether the new session is truly
> >
> > new, or
> >
> > > > if it's a new session because a previous session timed out. Could I
use
> >
> > a
> >
> > > > filter and check the incoming session ID and if the session ID isn't
in
> >
> > the
> >
> > > > list of session IDs that the server knows about, assume that it's an
> >
> > expired
> >
> > > > session?
> > >
> > > Yes, this may be the right solution. Store a hash in a singleton
> > > class and fill it with session ids that has expired (add a new hash
pair
> > > in every invocation of sessionDestroyed()). And at every request check
> >
> > that:
> > > 0) HttpSession.isNew()==true .
> > > 1) HttpServletRequest.getCookies() array contains an entry that
matches
> > > one of your hash pairs.
> > > That way you may determine if that session is truly new or an
> > > expired one. It's just a guess.
> > >
> > >
> > > -
> > > 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]
>
> -- 
> Ben Souther
> F.W. Davison & Company, Inc.
>
>
> This e-mail message, and any accompanying documents, is for the sole use
of
> the intended recipient(s) and may contain confidential and privileged
> information.  Any unauthorized review, use, disclosure, distribution or
> copying is prohibited.  If you are not the intended recipient, please
> contact our office by email or by telephone at (508) 747-7261 and
> immediately destroy all copies of the original message.
>
> -
> 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]



Re: Session Timeout and "Direct Reference to login page"

2004-05-20 Thread Ben Souther
What was wrong with the first suggestion?

1.) When your user logs in, throw an object in their session.
2.) In each servlet/jsp (or, better, in a filter), test for the existence of 
that object and forward back to the login if it is null.

Seems pretty straight forward to me.





On Thursday 20 May 2004 12:51 pm, Jonathan Eric Miller wrote:
> Yeah, that seems like it would work. I'm wondering if I could maybe use a
> filter by itself though and not use the listener and do something like the
> following.
>
> 1. Intercept all requests with a filter.
> 2. Get the HttpSession out of the request. Get the session ID by calling
> HttpSession.getId();
> 3. Get the cookie array and see if there is a cookie named "jsessionid." If
> there is, compare the two session IDs. If they are different forward to
> sessionexpired.jsp to display error page. Otherwise, continue as normal.
>
> This assumes that the session ID changes everytime it expires. As far as I
> know, that is the case.
>
> I would also have to figure out how to get the jsessionid if it is in the
> URL rather than in a cookie.
>
> I would prefer to do it that way if I can for the sake of simplicity. I
> want to avoid having a Hashtable that grows indefinitely if possible.
>
> Does it seem like this work, or, am I missing something?
>
> I'm wondering if this wouldn't work if I didn't have single sign-on
> enabled. i.e. the login page would get displayed at session expiration. I'm
> not sure if the login page does only forwards, or if it does a redirect.
> I'm thinking the redirect might make the above logic not work since the
> session ID in the cookie would get updated first by the login page. Note,
> the filter runs after the login page.
>
> It seems like there should be a generic way to handle this kind of thing
> that is well understood and known to work.
>
> Jon
>
> - Original Message -
> From: "Veniamin Fichin" <[EMAIL PROTECTED]>
> To: "Tomcat Users List" <[EMAIL PROTECTED]>
> Sent: Thursday, May 20, 2004 2:59 AM
> Subject: Re: Session Timeout and "Direct Reference to login page"
>
> > Jonathan Eric Miller wrote:
> > > Thanks. I think option #1 is what I'm looking for. What I don't
>
> understand
>
> > > is what I need to do with the session listener though?
> > >
> > > I don't understand how to determine whether the new session is truly
>
> new, or
>
> > > if it's a new session because a previous session timed out. Could I use
>
> a
>
> > > filter and check the incoming session ID and if the session ID isn't in
>
> the
>
> > > list of session IDs that the server knows about, assume that it's an
>
> expired
>
> > > session?
> >
> > Yes, this may be the right solution. Store a hash in a singleton
> > class and fill it with session ids that has expired (add a new hash pair
> > in every invocation of sessionDestroyed()). And at every request check
>
> that:
> > 0) HttpSession.isNew()==true .
> > 1) HttpServletRequest.getCookies() array contains an entry that matches
> > one of your hash pairs.
> > That way you may determine if that session is truly new or an
> > expired one. It's just a guess.
> >
> >
> > -
> > 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]

-- 
Ben Souther
F.W. Davison & Company, Inc.


This e-mail message, and any accompanying documents, is for the sole use of
the intended recipient(s) and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure, distribution or
copying is prohibited.  If you are not the intended recipient, please
contact our office by email or by telephone at (508) 747-7261 and
immediately destroy all copies of the original message.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Session Timeout and "Direct Reference to login page"

2004-05-20 Thread Jonathan Eric Miller
Yeah, that seems like it would work. I'm wondering if I could maybe use a
filter by itself though and not use the listener and do something like the
following.

1. Intercept all requests with a filter.
2. Get the HttpSession out of the request. Get the session ID by calling
HttpSession.getId();
3. Get the cookie array and see if there is a cookie named "jsessionid." If
there is, compare the two session IDs. If they are different forward to
sessionexpired.jsp to display error page. Otherwise, continue as normal.

This assumes that the session ID changes everytime it expires. As far as I
know, that is the case.

I would also have to figure out how to get the jsessionid if it is in the
URL rather than in a cookie.

I would prefer to do it that way if I can for the sake of simplicity. I want
to avoid having a Hashtable that grows indefinitely if possible.

Does it seem like this work, or, am I missing something?

I'm wondering if this wouldn't work if I didn't have single sign-on enabled.
i.e. the login page would get displayed at session expiration. I'm not sure
if the login page does only forwards, or if it does a redirect. I'm thinking
the redirect might make the above logic not work since the session ID in the
cookie would get updated first by the login page. Note, the filter runs
after the login page.

It seems like there should be a generic way to handle this kind of thing
that is well understood and known to work.

Jon

- Original Message - 
From: "Veniamin Fichin" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Thursday, May 20, 2004 2:59 AM
Subject: Re: Session Timeout and "Direct Reference to login page"


> Jonathan Eric Miller wrote:
>
> > Thanks. I think option #1 is what I'm looking for. What I don't
understand
> > is what I need to do with the session listener though?
> >
> > I don't understand how to determine whether the new session is truly
new, or
> > if it's a new session because a previous session timed out. Could I use
a
> > filter and check the incoming session ID and if the session ID isn't in
the
> > list of session IDs that the server knows about, assume that it's an
expired
> > session?
>
> Yes, this may be the right solution. Store a hash in a singleton
> class and fill it with session ids that has expired (add a new hash pair
> in every invocation of sessionDestroyed()). And at every request check
that:
> 0) HttpSession.isNew()==true .
> 1) HttpServletRequest.getCookies() array contains an entry that matches
> one of your hash pairs.
> That way you may determine if that session is truly new or an
> expired one. It's just a guess.
>
>
> -
> 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]



Re: Session Timeout and "Direct Reference to login page"

2004-05-20 Thread Ben Souther
In my case, I don't just want to test for a timed out session. I want to see 
if the session has timed out since the user has logged in.

So, when the user logs in, I add an object to the session (any object will 
do).  Then at the top of every servlet I test for the existence of that 
object 'if(session.getAttribute("myObject") == null)'.  If the object is null 
then I know that the session has timed out since the user last logged in.
At that point, I forward to the session expired page which informs the user 
that he/she must log back in.

It sounds like you're looking for something similar.


On Wednesday 19 May 2004 04:56 pm, Jonathan Eric Miller wrote:
> Thanks. I think option #1 is what I'm looking for. What I don't understand
> is what I need to do with the session listener though?
>
> I don't understand how to determine whether the new session is truly new,
> or if it's a new session because a previous session timed out. Could I use
> a filter and check the incoming session ID and if the session ID isn't in
> the list of session IDs that the server knows about, assume that it's an
> expired session?
>
> Does anyone have example source code on how to do this?
>
> Jon
>
> - Original Message -
> From: "QM" <[EMAIL PROTECTED]>
> To: "Tomcat Users List" <[EMAIL PROTECTED]>
> Sent: Wednesday, May 19, 2004 3:16 PM
> Subject: Re: Session Timeout and "Direct Reference to login page"
>
> > On Wed, May 19, 2004 at 02:58:05PM -0500, Jonathan Eric Miller wrote:
> > : All I want to do is detect when a session has timed out for a user and
> > : display a page stating such when the user makes a request after the
>
> session
>
> > : has timed out. It seems like this should be a straight forward thing to
>
> do.
>
> > : Am I missing something?
> >
> > You could use a session listener and check its existence with a
> > filter... In other words:
> >
> > // filter pseudocode
> > if( null != session.getAttribute( "UserMarker" ) ){
> > // pass the req and resp down the filter chain
> > }else{
> > // forward() to a "your session timed out" page
> > }
> >
> > Is this what you're after?
> >
> > Option #2: have each page meta-refresh to the "your session timed out"
> > page (set the refresh value 1 or 2 seconds beyond the session timeout).
> > This is more intrusive, though: people don't typically like it when
> > their browser starts moving around when they didn't explicitly ask.
> >
> > -QM
> >
> > --
> >
> > software  -- http://www.brandxdev.net
> > tech news -- http://www.RoarNetworX.com
> >
> >
> > -
> > 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]

-- 
Ben Souther
F.W. Davison & Company, Inc.


This e-mail message, and any accompanying documents, is for the sole use of
the intended recipient(s) and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure, distribution or
copying is prohibited.  If you are not the intended recipient, please
contact our office by email or by telephone at (508) 747-7261 and
immediately destroy all copies of the original message.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Session Timeout and "Direct Reference to login page"

2004-05-20 Thread Veniamin Fichin
Jonathan Eric Miller wrote:
Thanks. I think option #1 is what I'm looking for. What I don't understand
is what I need to do with the session listener though?
I don't understand how to determine whether the new session is truly new, or
if it's a new session because a previous session timed out. Could I use a
filter and check the incoming session ID and if the session ID isn't in the
list of session IDs that the server knows about, assume that it's an expired
session?
   Yes, this may be the right solution. Store a hash in a singleton 
class and fill it with session ids that has expired (add a new hash pair 
in every invocation of sessionDestroyed()). And at every request check that:
0) HttpSession.isNew()==true .
1) HttpServletRequest.getCookies() array contains an entry that matches 
one of your hash pairs.
   That way you may determine if that session is truly new or an 
expired one. It's just a guess.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Session Timeout and "Direct Reference to login page"

2004-05-19 Thread Jonathan Eric Miller
Renato,

Did you ever receive a response to this? I'm having the same problem.

My current problem is slightly more complicated though. I have my
application protected using container based security, but, I also have
single-sign on enabled. So, the user doesn't get redirected back to the
login page when the session times out.

Previously, I used to make it so that if the session had expired (detected
by my main JavaBean not being present (I was never able to figure out how to
determine whether it was a new session or one that had expired and hence
couldn't display an error message in the later case)), I'd just redirect the
user back to the first page of my application. However, now, I'm using
JavaServer Faces. As a result, I'm not the one implementing the controller
part of my application, JSF is.

Someone mentioned something about using HttpSessionListener. I don't see how
that can work because you don't have a handle to the request and response.

Is there a standard way of handling session timeouts?

All I want to do is detect when a session has timed out for a user and
display a page stating such when the user makes a request after the session
has timed out. It seems like this should be a straight forward thing to do.
Am I missing something?

Jon

- Original Message - 
From: "Renato Romano" <[EMAIL PROTECTED]>
To: "'Tomcat Users List'" <[EMAIL PROTECTED]>
Sent: Tuesday, March 02, 2004 3:31 AM
Subject: Session Timeout and "Direct Reference to login page"


> I have two problems i'm facing with every web application using
> declarative security model, that is:
>
> 1) Detect that the user session has expired, and forward him to an
> appropriate login page; Usually we build webapp in which the home page
> shows a login form; to handle this, I use to make a "index.jsp" page
> which redirects the user to a protected page; this is handled by the
> container which then shows my login page (as specified in web.xml) that
> is my HOME page. With this approach however, I can't detect session
> expirying, so if the session times out, the user is presented with the
> HOME page (the login
> page) without further notice or advice!! I tried to solve this with a
> filter, but it seems the container (Tomcat 4.1.127 inside Jboss)
> forwards to the login page without calling the filter.
>
> 2) If the user waits too long reading the home/login page, the sessions
> times out, Tomcat looses the reference to the previously requested
> protected page, and on login shows an "Invalid Direct refernce to form
> login page" error. Again a filter seem not to be useful in this case,
> since Tomcat commits the error without calling the filter!!
>
> Any help or hint on this topic is very, very appreciated
>
> Renato
>
>
> 
> Renato Romano
> Sistemi e Telematica S.p.A.
> Calata Grazie - Vial Al Molo Giano
> 16127 - GENOVA
>
> e-mail: [EMAIL PROTECTED]
> Tel.:   010 2712603
> _
>
>
>
>
>
> -
> 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]



Re: Session Timeout and "Direct Reference to login page"

2004-05-19 Thread QM
On Wed, May 19, 2004 at 02:58:05PM -0500, Jonathan Eric Miller wrote:
: All I want to do is detect when a session has timed out for a user and
: display a page stating such when the user makes a request after the session
: has timed out. It seems like this should be a straight forward thing to do.
: Am I missing something?

You could use a session listener and check its existence with a
filter... In other words:

// filter pseudocode
if( null != session.getAttribute( "UserMarker" ) ){
// pass the req and resp down the filter chain
}else{
// forward() to a "your session timed out" page
}

Is this what you're after?

Option #2: have each page meta-refresh to the "your session timed out"
page (set the refresh value 1 or 2 seconds beyond the session timeout).
This is more intrusive, though: people don't typically like it when
their browser starts moving around when they didn't explicitly ask.

-QM

-- 

software  -- http://www.brandxdev.net
tech news -- http://www.RoarNetworX.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Session Timeout and "Direct Reference to login page"

2004-05-19 Thread Jonathan Eric Miller
It's too bad there isn't a  element that you can put
in web.xml kind of like the  element...

Jon

- Original Message - 
From: "Jonathan Eric Miller" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, May 19, 2004 2:58 PM
Subject: Re: Session Timeout and "Direct Reference to login page"


> Renato,
>
> Did you ever receive a response to this? I'm having the same problem.
>
> My current problem is slightly more complicated though. I have my
> application protected using container based security, but, I also have
> single-sign on enabled. So, the user doesn't get redirected back to the
> login page when the session times out.
>
> Previously, I used to make it so that if the session had expired (detected
> by my main JavaBean not being present (I was never able to figure out how
to
> determine whether it was a new session or one that had expired and hence
> couldn't display an error message in the later case)), I'd just redirect
the
> user back to the first page of my application. However, now, I'm using
> JavaServer Faces. As a result, I'm not the one implementing the controller
> part of my application, JSF is.
>
> Someone mentioned something about using HttpSessionListener. I don't see
how
> that can work because you don't have a handle to the request and response.
>
> Is there a standard way of handling session timeouts?
>
> All I want to do is detect when a session has timed out for a user and
> display a page stating such when the user makes a request after the
session
> has timed out. It seems like this should be a straight forward thing to
do.
> Am I missing something?
>
> Jon
>
> ----- Original Message ----- 
> From: "Renato Romano" <[EMAIL PROTECTED]>
> To: "'Tomcat Users List'" <[EMAIL PROTECTED]>
> Sent: Tuesday, March 02, 2004 3:31 AM
> Subject: Session Timeout and "Direct Reference to login page"
>
>
> > I have two problems i'm facing with every web application using
> > declarative security model, that is:
> >
> > 1) Detect that the user session has expired, and forward him to an
> > appropriate login page; Usually we build webapp in which the home page
> > shows a login form; to handle this, I use to make a "index.jsp" page
> > which redirects the user to a protected page; this is handled by the
> > container which then shows my login page (as specified in web.xml) that
> > is my HOME page. With this approach however, I can't detect session
> > expirying, so if the session times out, the user is presented with the
> > HOME page (the login
> > page) without further notice or advice!! I tried to solve this with a
> > filter, but it seems the container (Tomcat 4.1.127 inside Jboss)
> > forwards to the login page without calling the filter.
> >
> > 2) If the user waits too long reading the home/login page, the sessions
> > times out, Tomcat looses the reference to the previously requested
> > protected page, and on login shows an "Invalid Direct refernce to form
> > login page" error. Again a filter seem not to be useful in this case,
> > since Tomcat commits the error without calling the filter!!
> >
> > Any help or hint on this topic is very, very appreciated
> >
> > Renato
> >
> >
> > 
> > Renato Romano
> > Sistemi e Telematica S.p.A.
> > Calata Grazie - Vial Al Molo Giano
> > 16127 - GENOVA
> >
> > e-mail: [EMAIL PROTECTED]
> > Tel.:   010 2712603
> > _
> >
> >
> >
> >
> >
> > -
> > 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]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Session Timeout and "Direct Reference to login page"

2004-05-19 Thread Ben Souther
Tomcat behaves according to the Servlet/JSP specs.
It creates a new session if a request is made after the previous one expires.
It's not too difficult to write your own, I did.

-Write a session-timeout.jsp  with a link to your login.

-Define a context-param in web.xml (session-timeout-page-url) or something 
like that, which defines the name of your session-timeout.jsp

-At the top of every servlet check for the existence of an object that get's 
put in session during login (an empty string will do).  If it's null, forward 
to the session-timeout.jsp.  Of course, you could also just forward straight 
to the login page and bypass the session-timeout.jsp altogether. 



If you're doing everything with JSPs, you could just use an include for the 
code that does the checking so you don't have to put the same code on the top 
of every JSP.

You could also do the same thing from a Filter.




On Wednesday 19 May 2004 04:35 pm, Jonathan Eric Miller wrote:
> It's too bad there isn't a  element that you can put
> in web.xml kind of like the  element...
>
> Jon
>
> - Original Message -
> From: "Jonathan Eric Miller" <[EMAIL PROTECTED]>
> To: "Tomcat Users List" <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Sent: Wednesday, May 19, 2004 2:58 PM
> Subject: Re: Session Timeout and "Direct Reference to login page"
>
> > Renato,
> >
> > Did you ever receive a response to this? I'm having the same problem.
> >
> > My current problem is slightly more complicated though. I have my
> > application protected using container based security, but, I also have
> > single-sign on enabled. So, the user doesn't get redirected back to the
> > login page when the session times out.
> >
> > Previously, I used to make it so that if the session had expired
> > (detected by my main JavaBean not being present (I was never able to
> > figure out how
>
> to
>
> > determine whether it was a new session or one that had expired and hence
> > couldn't display an error message in the later case)), I'd just redirect
>
> the
>
> > user back to the first page of my application. However, now, I'm using
> > JavaServer Faces. As a result, I'm not the one implementing the
> > controller part of my application, JSF is.
> >
> > Someone mentioned something about using HttpSessionListener. I don't see
>
> how
>
> > that can work because you don't have a handle to the request and
> > response.
> >
> > Is there a standard way of handling session timeouts?
> >
> > All I want to do is detect when a session has timed out for a user and
> > display a page stating such when the user makes a request after the
>
> session
>
> > has timed out. It seems like this should be a straight forward thing to
>
> do.
>
> > Am I missing something?
> >
> > Jon
> >
> > - Original Message -
> > From: "Renato Romano" <[EMAIL PROTECTED]>
> > To: "'Tomcat Users List'" <[EMAIL PROTECTED]>
> > Sent: Tuesday, March 02, 2004 3:31 AM
> > Subject: Session Timeout and "Direct Reference to login page"
> >
> > > I have two problems i'm facing with every web application using
> > > declarative security model, that is:
> > >
> > > 1) Detect that the user session has expired, and forward him to an
> > > appropriate login page; Usually we build webapp in which the home page
> > > shows a login form; to handle this, I use to make a "index.jsp" page
> > > which redirects the user to a protected page; this is handled by the
> > > container which then shows my login page (as specified in web.xml) that
> > > is my HOME page. With this approach however, I can't detect session
> > > expirying, so if the session times out, the user is presented with the
> > > HOME page (the login
> > > page) without further notice or advice!! I tried to solve this with a
> > > filter, but it seems the container (Tomcat 4.1.127 inside Jboss)
> > > forwards to the login page without calling the filter.
> > >
> > > 2) If the user waits too long reading the home/login page, the sessions
> > > times out, Tomcat looses the reference to the previously requested
> > > protected page, and on login shows an "Invalid Direct refernce to form
> > > login page" error. Again a filter seem not to be useful in this case,
> > > since Tomcat commits the error without calling the filter!!
> > >
> > > Any help or hint on this to

Re: Session Timeout and "Direct Reference to login page"

2004-05-19 Thread Jonathan Eric Miller
Thanks. I think option #1 is what I'm looking for. What I don't understand
is what I need to do with the session listener though?

I don't understand how to determine whether the new session is truly new, or
if it's a new session because a previous session timed out. Could I use a
filter and check the incoming session ID and if the session ID isn't in the
list of session IDs that the server knows about, assume that it's an expired
session?

Does anyone have example source code on how to do this?

Jon

- Original Message - 
From: "QM" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, May 19, 2004 3:16 PM
Subject: Re: Session Timeout and "Direct Reference to login page"


> On Wed, May 19, 2004 at 02:58:05PM -0500, Jonathan Eric Miller wrote:
> : All I want to do is detect when a session has timed out for a user and
> : display a page stating such when the user makes a request after the
session
> : has timed out. It seems like this should be a straight forward thing to
do.
> : Am I missing something?
>
> You could use a session listener and check its existence with a
> filter... In other words:
>
> // filter pseudocode
> if( null != session.getAttribute( "UserMarker" ) ){
> // pass the req and resp down the filter chain
> }else{
> // forward() to a "your session timed out" page
> }
>
> Is this what you're after?
>
> Option #2: have each page meta-refresh to the "your session timed out"
> page (set the refresh value 1 or 2 seconds beyond the session timeout).
> This is more intrusive, though: people don't typically like it when
> their browser starts moving around when they didn't explicitly ask.
>
> -QM
>
> -- 
>
> software  -- http://www.brandxdev.net
> tech news -- http://www.RoarNetworX.com
>
>
> -
> 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]



Session Timeout and "Direct Reference to login page"

2004-03-02 Thread Renato Romano
I have two problems i'm facing with every web application using
declarative security model, that is:

1) Detect that the user session has expired, and forward him to an
appropriate login page; Usually we build webapp in which the home page
shows a login form; to handle this, I use to make a "index.jsp" page
which redirects the user to a protected page; this is handled by the
container which then shows my login page (as specified in web.xml) that
is my HOME page. With this approach however, I can't detect session
expirying, so if the session times out, the user is presented with the
HOME page (the login
page) without further notice or advice!! I tried to solve this with a
filter, but it seems the container (Tomcat 4.1.127 inside Jboss)
forwards to the login page without calling the filter.

2) If the user waits too long reading the home/login page, the sessions
times out, Tomcat looses the reference to the previously requested
protected page, and on login shows an "Invalid Direct refernce to form
login page" error. Again a filter seem not to be useful in this case,
since Tomcat commits the error without calling the filter!!

Any help or hint on this topic is very, very appreciated

Renato



Renato Romano
Sistemi e Telematica S.p.A.
Calata Grazie - Vial Al Molo Giano
16127 - GENOVA

e-mail: [EMAIL PROTECTED]
Tel.:   010 2712603
_





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Session Timeout and "Direct Reference to login page"

2004-03-01 Thread Renato Romano
I have two problems i'm facing with every web application using
declarative security model, that is:

1) Detect that the user session has expired, and forward him to an
appropriate login page;
Usually we build webapp in which the home page shows a login form; to
handle this, I use to make a "index.jsp" page which redirects the user
to a protected page; this is handled by the container which then shows
my login page (as specified in web.xml) that is my HOME page.
With this approach however, I can't detect session expirying, so if the
session times out, the user is presented with the HOME page (the login
page) without further notice or advice!! I tried to solve this with a
filter, but it seems the container (Tomcat 4.1.127 inside Jboss)
forwards to the login page without calling the filter.

2) If the user waits too long reading the home/login page, the sessions
times out, Tomcat looses the reference to the previously requested
protected page, and on login shows an "Invalid Direct refernce to form
login page" error. Again a filter seem not to be useful in this case,
since Tomcat commits the error without calling the filter!!

Any help or hint on this topic is very, very appreciated

Renato



Renato Romano
Sistemi e Telematica S.p.A.
Calata Grazie - Vial Al Molo Giano
16127 - GENOVA

e-mail: [EMAIL PROTECTED]
Tel.:   010 2712603
_



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]