How to detect "inactivity" in a GWT application.

[stuckagain]

We are trying to migrate some old fat client application to GWT and we
need to implement a mechanism that detects user inactivity to know
when to close the session.

Traditional web applications normally just use a session timeout
mechanism and force the user to login again when the session expires.
A GWT application however can run for a long time without any need of
server interaction. If we want to use server side sessions (which are
sometimes really needed), then we need to use a very long session
timeout or the client must keep the session open as long as the
application is being used.

We rather keep a short session timeout setting (15-20 minutes) and
send a ping every 12-14 minutes to make sure that the server keeps the
session open. I know that polling is considered evil, but the number
of clients is not that great but the sessions can hold a lot of state,
so we want to get rid of it as soon as possible.

The problem we are now facing is ofcourse: how do we detect inactivity
of the user... because if a user does not use the application for some
time, we want to either block his GUI or even log him out
automatically.

I've been looking through the GWT event handling mechanism and I see
there is something called Event Preview. This is almost exactly what I
need, but with the difference that it uses a stack and only the top
node on the stack gets a preview of all the events. So if a popup
panel is used, I will not get my events anymore.

Is there a way to make sure that I always get Key and Mouse events in
my GWT app (without needing to hack the DOMImpl classes ?).

It would be nice if GWT supported this kind of operation.

[Dave]

You could use a Timer on the client side and call an RPC method to see
if the user's
session has timed out if you are maintaining a session on the server
side.

Dave

[stuckagain]

No,

That is not the solution. The Point is: a GWT application needs less
server interactions so that means that the server side could expire
while the client is still active. So, we have to either increase the
session timeout on the server - which can cause a lot of stale session
remaining too long in memory, or we must keep the session timeout
small but use a timer to keep it alive. This timer must stop when we
detect that the user is no longer using the application.

What I want to achieve is that the server session can only timeout
after I am certain the client is no longer their (hence the polling
aproach). But if I use a Timer to keep the session open, then I need
to detect when the user is no longer there.

When developing banking software we have to protect the user against
his own stupidities. So if the user goes off too lunch and he remains
logged in in our application, we must make sure that his session
expires or that we lock the application automatically.

David

> > It would be nice if GWT supported this kind of operation.- Hide quoted text -
>
> - Show quoted text -

[mP]

Unfortunately you cant watch all events without using EventPreview.
The EP thing wont work because what happens if you already have one EP
registered, you cant register a second EP and have them btoh seeing
events because only one is ever active.

[Sandy McArthur]

On 6/18/07, stuckagain <david...@gmail.com> wrote:
>
> No,
>
> That is not the solution. The Point is: a GWT application needs less
> server interactions so that means that the server side could expire
> while the client is still active. So, we have to either increase the
> session timeout on the server - which can cause a lot of stale session
> remaining too long in memory, or we must keep the session timeout
> small but use a timer to keep it alive. This timer must stop when we
> detect that the user is no longer using the application.

Or, choice #3, include enough information with every RPC request to
recreate the session when needed again.

I plan to use that technique to support a use case of a logged in user
puts their laptop to sleep at work, goes home, eats dinner, and 4
hours later opens the laptop back up and can continue working right
where they left off.

--
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

[stuckagain]

I know, but it would be nice if I could get something else so that I
can, sort of "replace" the event handling with my own customized
version.

> > > - Show quoted text -- Hide quoted text -

[stuckagain]

Sandy,

That works for many applications, but in our case there is a security
reason why I can not put certain information in the client nor in a
database.

For example: an ecryption key that is used to secure the messages send
out by the backend. This key is generated during login to a backend
and I can not put it in a database (for security reasons as well - the
banking industry is very paranoid :-)). I can not put it in the client
because it could be stolen there (when a user leaves his desktop
unattended).

There are so many situations where you want to protect your
application from possible malicious users. If you would put security
sensitive information in the GWT client side, then the user can start
abusing this information. We can not afford this to happen.

David

On Jun 19, 12:25 am, "Sandy McArthur" <sandy...@gmail.com> wrote:

[AndyInSouthend]

How about making a 'keep-alive' call to the server each time the
client carries out an action that is deemed worthy of such a call?

[David Goodenough]

Why not adopt the kind of function used by hardware watchdog timers.

So in every user interaction that counts as them "doing something" call a
method in a static class which sets a boolean to say that this was done.
Then when the static object is created start a periodic timer, and check
that the done bit is set, if not then send the ping to the server to keep
the session active and reset the done bit.

David

[stuckagain]

David,

That could work, but I like to solve issues in one location. Now I
must make sure that all developers on the project call this method
when user interaction occurs. In fact they should call this method on
every user interaction they handle.

I guess I could start implementing base implementations of all event
listener interfaces and force the developpers to subclass from that
base implementation instead of directly implementing the event
listeners.

I still hope that the GWT teams opens up the event handling a bit, it
is common to do these things in other GUI toolkits.

Thanks for all the help, at least I have some workaround now!
David

On Jun 19, 12:09 pm, David Goodenough <david.goodeno...@btconnect.com>
wrote:

> David- Hide quoted text -

[cheleb]

Hi all,
When polling (server side) you can set/reset a Timer Task.
This TimerTask fires a logout event (and invalidate the session) when
scheduled.
When action occured (client side) you put some data in the pooling
call/request.
A polling request with data reset (cancel + set) the Timer Task
whereas an empty polling request does not.
Its should work, but create 1 task / timer per session.

hih