Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

Thread: How to limit logons?

  1. #11
    Join Date
    Aug 2004
    Location
    Sydney, Australia
    Posts
    2,768

    Default

    ContextHolder should be null unless the web container is actually processing a request for the principal. Can you get the authentication from the HttpSession?

  2. #12
    Join Date
    Aug 2004
    Location
    Allentown, PA
    Posts
    141

    Default

    gtuberson,

    Thanks. I ended up storing it in there as well.

    Dan

  3. #13
    Join Date
    Aug 2004
    Location
    Southern Germany
    Posts
    30

    Default

    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.
    Regards,
    Lars Fischer
    http://j2ux.blogspot.com

  4. #14
    Join Date
    Nov 2004
    Posts
    3

    Default closing the browser

    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]

  5. #15
    Join Date
    Aug 2004
    Location
    Sydney, Australia
    Posts
    2,768

    Default

    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.

  6. #16
    Join Date
    Nov 2004
    Posts
    3

    Default

    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.

    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

Similar Threads

  1. SWF size limit on Weblogic?
    By ruipacheco in forum Web Flow
    Replies: 4
    Last Post: Sep 19th, 2005, 05:19 AM
  2. Redirection Limit error
    By jdoklovic in forum Security
    Replies: 5
    Last Post: Sep 8th, 2005, 09:49 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •