Realtime messaging and session timeout

[jpappalardo]

So I am trying to implement relogin on session timeout. So I added to web.xml:

    <session-config>
        <session-timeout>1</session-timeout>
    </session-config>

and implemented the login failed marker, and was hoping I understood what I was doing and would see a dialog to log back in after being idle for a minute and then trying to interact in a way that hit a protected url. Much to my dismay, the session does not appear to ever timeout. And as I watch firebug, the only logical conclusion I can come to, is that realtime messaging is actually keeping my session alive. Which really is not a desirable solution.

I am using the settings provided in the documentation:

# how often do we send keepalives to the client (ms)
messaging.keepaliveInterval: 3000
# how long the client waits after the keepaliveInterval before re-establishing
# the connection (ms)
messaging.keepaliveReestablishDelay: 1000
# how long the client waits for the connect handshake to complete before
# retrying
messaging.connectTimeout: 4000
# connection time to live - the maximum amount of time a persistent connection
# is allowed to stay open before being re-established (ms)
messaging.connectionTTL: 120000
# total response size to pad out to in order to defeat intervening
# bufferring by proxies (bytes)
messaging.flushBufferSize: 8096
# dispatcher to use for user registration/message queueing
# com.isomorphic.messaging.LocalMessageDispatcher for simple one-jvm messaging
# com.isomorphic.messaging.JMSMessageDispatcher for JMS-backed messaging
messaging.dispatcherImplementer: com.isomorphic.messaging.LocalMessageDispatcher

How can I configure all of this in a reasonable manner where I still get timely server push, and yet client sessions expire when no actual user activity happens?

--NOTE--
Obviously I set session timeout to 1 just in the hopes of making debug easier, and is not a realistic value.

[Isomorphic]

Yup, this is a problem that comes up with all streaming web applications. The solutions fall into two categories:

1. detect inactivity rather than lack of contact with the server, then log the user out client-side. In GWT this is generally done with EventPreview - explanation of usage is toward the bottom here

2. have a separate server for streaming, such that the primary session expires normally. This is much more complicated - the two servers need to be incorporated into the same webapp via document.domain, and the primary server needs to manually create and destroy sessions on the streaming server to allow authenticated access. Only go this route if security is so important that a client-side logout isn't going to be sufficient.

[Isomorphic]

Actually, for completeness, let's cover a third option:

3. send back a token with every non-streaming-related response that should be used on the non-streaming request. If you get a token that's too old, expire the session on the server side.

This is a bit like the manual session management of #2 but generally simpler although it has edge cases.

You can send tokens on every request *for data* by adding URL parameters to RPCManager's default actionURL.

Consider also that out-of-order responses and requests may need to be handled depending on how your UI is structured. This necessitates keeping track of an array of recently vended tokens on the server.

[amcculley]

Actually, the Messaging keep alive by itself will not prevent a session from being invalidated on the server.

However, if your messaging callback or listener is doing something like refreshing a grid, row, etc, then yes - it will prevent the session from being invalidated since it makes calls to the server to get data.

[Isomorphic]

It actually will keep the session going, because the connection is torn down and re-established every 2 minutes by default, so this involves a new request.

It has to be torn down and re-established this way because otherwise, it will time out at 4 minutes, or sooner depending on the configured behavior of intervening proxies and firewalls.

[amcculley]

I know this falls outside the realm and scope of SmartGwt and falls into general Java EE knowlege but we are really struggling to come up with a good solution for this. Unfortunately, client-side handling isn't good enough for security.

First off - this is pretty trivial in a non-clustered environment. That works. In a clustered environment, this is far from trivial.

The issue we are having, even with the token approach, is that we don't have any way of keeping a distributed copy of HttpSession references so that invalidate() can even be called. It is easy to store....

Nevermind - I just thought of such an easy way to do this. Instead of trying to code around Messaging, use it to our advantage.

Since Messaging fires a request every 2 minutes, do a check there to see how long it has been since the last non-streaming access has been. Since we can store that as a timestamp inside the session itself, it will get replicated to all other nodes.

So, at most, if Messaging is used, the timeout will be off by 2 minutes. If messaging is not used, then the normal container-based timeout will work just fine.