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. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/Jtbckmvs3IEJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
