ContextHolder should be null unless the web container is actually processing a request for the principal. Can you get the authentication from the HttpSession?
ContextHolder should be null unless the web container is actually processing a request for the principal. Can you get the authentication from the HttpSession?
gtuberson,
Thanks. I ended up storing it in there as well.
Dan
What is the easiest way to lock users after a predefined number of attempts regardless of the session aspects mentioned in this thread ?
I need to implement this for a new application and would appreciate any help.
Limiting the logins is working using the approach described above, except when the user close the browser without loging out.
If the user close the browser, the corresponding session will still be valid in the server, since there is no logout or time out yet.
If the user close the browser and then opens it again and tries to login, it will get the message that its user id is already login somewhere. The user would have to wait for that session to timeout.. this is not good.
I am trying to find out a way to capture the window onclosed event.. but there is no such event in javascript.. for IE there is a way to capture it with the window.onunload envent + some javascript logic to differentiate a page unload from a real window closed event; however I haven't found anything for Netscape or Mozilla..
any ideas? it will be appreciatted.
If I can not capture the window onclose event, I was thinking about
using two different daoAuthenticationProvider, one for the Login, and the other for the periodic authentication that ACEGI does behind the scenes. The login authentication would stored the sessionId in the database. The periodic authentication will compare the sessionId of the HTTPserveletrquest with the database, if different it will invalidate the http session, sending a message like "another user has login with this userId and password".. But I haven't tried at all this approach yet.. I am working in the window onclose event[/quote]
I am pretty sure you can't capture a window on close event unless the application created the window. Thus many webapps have a "start using the app" link which opens a popup, as the popup can have its close event captured and if desired redirect to a logout page instead (it can also take away the URL bar and back button, which is often useful).
I cannot see how at a web browser level you can differentiate between:
1. A closed browser, where the corresponding HttpSession has not timed out, so you want to allow another login; and
2. An still active browser, and the user loading another active browser, and login being allowed (just in case #1 applied).
Perhaps the easiest approach is to end sessions using HttpSessionListener and relying on users logging out (perhaps with the help of window close event capturing), which will resolve 80% of your issues. For the remaining 20%, maybe display a "this user is already logged in" message and ask for confirmation the user is no longer active. If they confirm, set a database column, "session_terminated", to true. Then if a subsequent request comes in for the original session, your authentication provider could throw a TerminatedSessionReusedException.
Thank you Ben, I have implemented the above logic and it is working.For the remaining 20%, maybe display a "this user is already logged in" message and ask for confirmation the user is no longer active. If they confirm, set a database column, "session_terminated", to true. Then if a subsequent request comes in for the original session, your authentication provider could throw a TerminatedSessionReusedException.
I did something a little different, I am not using a "session_terminated" database colum, I am throwing the TerminatedSessionReusedException whenever the Authentication.SessionId is different than the User(database).SessionId.
The AuthenticationSuccessEvent was not being fired for the user that login after confirming (two steps) because the user was already in Cache. I am throwing this event in my CustomDaoAuthenticationProvider.isPasswordCorrect.
if the SessionId are found different, I had to check if I am using a user from the Cahe, if this is the case, I am not sending the Exception yet, I get the user from the BackEnd and repeat the check.. all of this within the
CustomDaoAuthenticationProvider.isPasswordCorrect.
To send the TerminatedSessionReusedException was not that easy because the SecurityEnforcementFilter was not setting the Exception object as an attribute of the HttpSession. I had to inherit SecurityEnforcementFilter an overwrite the sendAccessDeniedError method to attach this object to the HttpSession
Now I am getting all these messages that let the User know what is happening, and let the user Login even if he forgot to logout before closing the browser. We don't have two sessions active with the same UserId.
Thank you again for your guidance,
Zenobia