get login user details on client side with Spring Security

[liudi]

Hi,

Spring Security makes the authentication process in SmartGwt extremely powerful and convenient, that is brilliant, but i got a slight problem here.

in my application, the client side needs to obtain login user information in order to create GUI, determine what to show and what to do based on user role attribute. My application generally has 5 main classes for different pages/functionalities. In every class, there's a couple of lines of code to asynchronously retrieve user information stored in the current session, and then use this info to establish/show certain views of the GUI accordingly.

With Spring Security, when the session is timed out, or the user is trying to access a protected resource, a popup window will display to prompt the user to login, if the login succeeds, it the RPCManager resends the transaction, hence the user action is continued seamlessly.

Here's the scenario

1. user DAVID logs in, opens up the search page(the login user info for DAVID is loaded to the client side), and leaves the computer

2. 30 minutes later, user JOHN comes to the computer, and clicks on the 'Search' button, because the session has timed out, so JOHN is prompted to login again. He uses his username to login successfully.

3. now, the client side login user info contains the details of DAVID, but current login user is JOHN. If these two users have different access level, and different views are displayed for each of them, then JOHN is going to see DAVID's page, that's wrong.

I m thinking of refresh the whole page every time when a user logs in, but this way the benefits of 'Resent Transaction' will no long available.

any idea about this? thank you!

[laurentJ]

I did the following :
- keep current user info (username, last login date, authorities) in the main module
- upon a successfull login, clear any existing data related to a potentially previous user
- request user info from server through a RPC request
- refresh user info in main module, eventually updating the other modules

[aquajax]

http://forums.smartclient.com/showth...hlight=relogin

This forum has a good discussion on relogin using spring security with SmartGWT. Requires quite a lot of work to get going completely. I have only done some of this so do not have relogin working completely but one tip I can give is that if you follow this forum and use the RPC for UserDetailsServlet that as you know RPC is asyncronous so if you want to manage the logged in user at the client to show/hide UI based on user role then you really need to build your UI or atleast call the method to build your UI from the callback or when you do the checks user's role when drawing components the initial RPC call will not have completed.

As I have not completed the relogin scenerio I have not thought through how to reset UI component visibility on relogin but again will need to do something from the RPC callback but i dont really want to have to store references to every securable UI element so I can go back throguh and set visibility when the logged in user changes but this may be what is required.

In your scenerio you are thinking of a page refresh which would probably solve my problem, depending on how you get the credentials from the user for the relogin you may navigate away from the page and back to it but if you dont then hve my problem from above on how to reset UI component visibility.

[Isomorphic]

Best practice is definitely to reload the page if relogin is used to actually switch user id. There is no value to the end user in trying to build the UI in such a way that you can dynamically switch the user's role - it most cases this would be undesirable. Also, it's both very difficult and in most cases would be tantamount to reloading the page anyway (consider the possibility of data having been loaded that the new user should not see - so that has to be dropped..).

[liudi]

Thanks guys! yes i think the only way is to refresh the page if a different user logs in.

what i m going to do is to relogin first, and then compare the session user info with the client stored user info, if the usernames are the same, do resend transaction, and keep the page unchanged; if the usernames are different, do not resend transaction, refresh the page and reload user information to the client side.

Thnaks again for the help!