I appreciate the response, but you're a complete and total ass. I do not know why people let you get away with acting the way you do. We come here for help, not abuse. We're not idiots, we simply don't understand the subject as well as you do. I've seen your other responses, and you are just as rude. While I am sure that you understand this subject better than anyone else, I would appreciate it if you could refrain from responding to this thread until you learn to display tact and manners.
That said... I understand how the server identifies which state bag to relate to a client request (JSESSIONID). What I don't understand is how sending a unique ID along with each RPC request does anything since I am not looking up the session state on the server side, it is automatically provided to me via the HttpServletRequest.getSession() method. If I was looking up values in a database based on the client identifier (for authorization let's say), then I realize that it is better to have the application provide the unique ID instead of relying on the client sending the Tomcat server a JSESSIONID. However, I am ONLY using the session for a state bag. The authentication is happening against another server (for example's sake, say LDAP) and I simply get back an authentication token that I persist into the session. For example, let's say there are 4 GWT-RPC methods: 1) boolean login(String username, String password) 2) boolean logout() 3) boolean isLoggedIn() 4) String getFoo() Now, imagine this series of events: 1) The GWT app loads and isLoggedIn() is called to see if the user already has logged into the back-end server via the GWT Impl class. The Impl class checks to see if there is a valid "logon token" for the user stored in a Session attribute. If there is it returns true; otherwise false. 2) If the user is not logged in they are presented with a login view. The user enters their username and password and the login(String, String) method is invoked. The Impl class calls the LDAP server and the login succeeds, returning a token. The token is stored in the session and a true value is returned to the client. 3) The user then clicks on a button that invokes the getFoo() method which cause the Impl class to use the previously obtained logon token to invoke an operation on an LDAP-enabled service somewhere. 4) The user logs out, and the session is invalidated. Now, in this scenario the user isn't logging into the GWT app so much as they are validating credentials with a third-party authentication mechanism. If they are valid then they can move beyond the "login" view to some meaningful controls. If their session expires then they are forced to login again. This may happen if they close their browser, or however it happens. I am not concerned with persisting the "login" beyond the length of their browser session because the lifetime of the login token that the LDAP (not really LDAP in my case) server returns isn't infinite, and even if I let the user stay logged in for 2 weeks according to the web app, they would still need to re- authenticate to the LDAP server after X amount of time (likely to be much shorter than the interval that I would set). That is the scenario I am faced with. I am HAPPY to send along the unique client ID each time that could be returned by the login operation, however, what would I do with it? Basically check to make sure that the ID that subsequent requests send me is the same that was originally generated? If this is case then I can see Reinier's point and am happy to implement said feature. I am just trying to understand the situation. Thank you! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
