Multiple GWT sessions possible?

[Mike Dee]

After moving an app from a traditional web app (think PHP or similar scripting language) to a GWT app I noticed a difference in handling of sessions.  It seems like it is possible to have multiple simultaneous sessions with a GWT app running in the same browser (different tabs or windows).  Not sure if this is a correct understanding or I am out in space some where.  Also, concerned about potential security flaws with this.

In our case, once a user is logged in, we create a session variable (server side). The value is not important.  We simply check for its presence with every GWT-RPC call (server side).  If the variable is not there, we throw an exception - to signal a timeout - which is caught by the GWT app and the user must log in again.

Once the user is logged in, we don't really use the session (accept to check for its existence, as mentioned above). We do keep the user id on the client side - in the GWT client app though.  Most of the calls to the server (via GWT-RPC) are not user specific.  They are mostly queries.  When the user is needed, the user ID is passed through GWT-RPC to the server. 

This is where a GWT app seems to really differ from a traditional web app. Each instance of a GWT app can store its own user ID.  These are stored in the GWT client app (JS variables).  Thus it seems like multiple instances of a GWT app can be run (for example, in two tabs of the same browser), with each instance being logged in as a different user.  They would, of course, share the same session.  In general, this is not likely to be done with a traditional web app because they typically rely on cookies to identify the user to the server and there is typically one cookie per web app (not per instance of the app).

This idea still seems a little strange to me, coming from a world other than GWT.  Does this makes sense or am I missing something?

[Frank Hossfeld]

If you are able to design the server side of an GWT app, you should use stateless services.

[Jens]

You should always always always keep track which user is logged in on server side just because of security. If you have user roles, permissions, secured areas in your application then you should not trust by all means what the client sends you. An attacker has full control of the source code of your GWT client side application. He could fake user IDs, assigned roles/permissions if you only store them on client side without verification on server side. Your server must be rock solid. Security information on the client are just cosmetic so you can show/hide UI controls that you have access/no access to.

Also each of your GWT-RPC requests should also send a security token in its payload that you check on the server to avoid CSRF attacks.

Typically a HttpSession on server side only represents a browser instance and thats it (done via the session cookie set by your application server). To "connect" it to the logged in user you have to store something in the session that depends on that particular user. This can be the user_id or some kind of a token that represents the logged in user. This information should be stored on the client and send to the server on each request so it can be compared against the value in the server side session. Without any further logic this would limit you to one active user session on client side (session.get(USER_ID_KEY)).

For multiple client session you should calculate a token that identifies the browser window/tab, so you would extend the typical app server session that only identifies the browser instance itself. In your app server session you would store [<tab/window-session-id>, new HashTable()] and then use the HashTable to store session information instead of the session directly (HashTable because of thread safety). So the user_id/token mentioned before would go into the tab-session to connect the tab-session with the logged in user. Like the app server session id, the tab session id also has to be stored on the client.

So in short: trusting the user_id coming from client side is a bad idea if you don't have other means to identify an user on server side.

-- J.

[Joseph Lust]

All good points from Jens.

But, perhaps I'm missing something, but on most servers (Apache with mod_php, Tomcat) set a session token in the cookie on the first request you make to the server. Once the user logs in, you associate this session with that user by persisting their data data in $_SESSION or a session scoped bean. To that end, if you had your app open in one window, or 10 windows, they should all be on the same session because they are all passing the same session id cookie.

Assuming that you're doing that, then a mechanism like Spring Security that would allow you to secure a context like "**/secure/*" to a given role (i.e. User) would be all you needed to do to protect your services/RPC's

The one catch is application timeout. To get around this I return an HTTP error code (i.e. forbidden) and then have that caught in the failure handler for the RPC's. I extended the typical callback handler so all RPC's can handle session termination in a consistent, graceful way, prompting them to login again. With Spring Security you can even setup the request to us remember me cookies (if user selected that on login). In that case the server will cache the request, log the user back in, and forward the request, making the session timeout/relogin invisible to the user.

Hope that helps.

Sincerely,

Joseph

[Jens]

But, perhaps I'm missing something, but on most servers (Apache with mod_php, Tomcat) set a session token in the cookie on the first request you make to the server. Once the user logs in, you associate this session with that user by persisting their data data in $_SESSION or a session scoped bean. To that end, if you had your app open in one window, or 10 windows, they should all be on the same session because they are all passing the same session id cookie.

Thats exactly what I mean with "one active session on the client". Only a single user is authenticated in all browser windows/tabs because you only have a single cookie with a single session id. You must log out or delete cookies if a second user should see the login screen again on the same browser (or you need a session timeout on server).

 

The one catch is application timeout. To get around this I return an HTTP error code (i.e. forbidden) and then have that caught in the failure handler for the RPC's. I extended the typical callback handler so all RPC's can handle session termination in a consistent, graceful way, prompting them to login again. 

Its always a good idea to use a custom base class for RPC callbacks and/or use a custom RequestTransport/RpcRequestBuilder to handle these server responses. Its not only common HTTP error codes but also common exceptions like SerializationException/IncompatibleRemoteServiceException (GWT-RPC) that would indicate an application update that occurred while the user was idle in the app.

-- J.

[Daniel Kurka]

On Tuesday, December 11, 2012 11:20:40 AM UTC+1, Jens wrote:

You should always always always keep track which user is logged in on server side just because of security. If you have user roles, permissions, secured areas in your application then you should not trust by all means what the client sends you. An attacker has full control of the source code of your GWT client side application. He could fake user IDs, assigned roles/permissions if you only store them on client side without verification on server side. Your server must be rock solid. Security information on the client are just cosmetic so you can show/hide UI controls that you have access/no access to.

Also each of your GWT-RPC requests should also send a security token in its payload that you check on the server to avoid CSRF attacks.

You will not need a server side session for this. If the client sends some kind of authentification with each request there is no need for a session and you will loose all the complexity of what happens with multiple tabs / deleting cookies.