Hi Rick,
It's past midnight here so I'll check the code tomorrow. A few questions
though...
1) For one, the business requirement created a bit more complication
in the filter. For example a check for the session timing out has to
take place on all pages except for (index.jsp/login/logout/appinuse).
I'm doing this check in the filter by checking for the session being
null, but it created complications of when to force a new one, which
is needed for the 'invalidate' check.
I'd love some help with the ugly logic I have (which I'll post at end
of this doc). I know it can be cleaned up, but you know how it is when
your trying a million different if/else things and your brain is
frazzled:)
Could you clear this situation for me:
User A is using the app, then his session expires.
User B starts to use the app.
User A comes back and want to access a page in the app. Remember that
his session is expired and User B is already using the app.
You redirect him to index.jsp? Or to appInUse.jsp?
At first I would say that you could use a second filter which checks for
expired session.
This way the situation will be clear.
One filter limits the sessions the other filter checks for timeouted
sessions.
2) I noticed a lot of odd behavior when the server was shut down and
the pages were still up. For example, if the user was left on a page
that displayed a "log off" link and the server was restarted, when
they then clicked on log off (which calls session invalidate) it would
decrement the sessionCounter to -1. I'm not sure how sessionDestroyed
could get called before sessionCreated, but I guess it can? My hack
here was to do a check for sessionCount being less than 0 and if so
reset it to 0.
This is strange. What kind of webcontainer do you use?
At first glance it seems like your web container has a 'feature' to
serialize sessions on stop and to recreate them when you start the
server again.
In this case the sessionCounter would be set to 0 on restart but the
session would be recreated => no sessionCreated() executed, just
sessionDestroyed() on logout...
3) Using <[EMAIL PROTECTED] session="false" %> didn't seem to call the
sessionDestroyed method, which I really need to have happen when they
hit the logoff and appinuse.jsp. I went back to using <%
session.invalidate(); %> (I haven't looked at the docs on
session="false" for JSPs does that just make sure a new Session isn't
created?)
If you use
<[EMAIL PROTECTED] session="false" %>
your session implicit object will not be initialized.
If you use
<[EMAIL PROTECTED] session="true" %>
in the translated servlet you will have a line:
session = request.getSession();
So if you want to use session.invalidate() you cannot use <[EMAIL PROTECTED]
session="false" %>.
I used <[EMAIL PROTECTED] session="false" %> only in appInUse, not in logoff.
I used it because otherwise a new session will be created when you
redirect to the appinuse.jsp from the filter.
The session will be flagged for invalidation, but because we just let
through all the request to appInUse.jsp
in the filter the sesiion will not be invalidated.
OK here is the filter that I'd love some clean up on. There must be a
way to make this less ugly...you can try this link to see the full
version:
I will check it tomorrow...sorry
Tamas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
