Announcement Announcement Module
Collapse
No announcement yet.
Interesting Login issue Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Interesting Login issue

    My implementation
    - I have implemented UserDetailsService
    - I have also extended User class for my own implementation
    - To capture session events, I have extended HttpSessionEventPublisher

    Steps that creates issue

    1. Login into app.After successfully login forwarded to default-target-url

    I have configured logger and it the flow is like this
    - It goes to UserDetailsServiceImpl
    -- I prepare myUser class (extend User) object and return it from method loadUserByUsername() . I have set one property called employee id, this is application specific. let's say for this user employee id 100
    - then it goes to SessionCreated method of extension of HttpSessionEventPublisher. I print employee id and it prints 100 which I have set in UserDetailsServiceImpl

    2. Open another tab in same browser
    3. login again with different credentials

    - Same, it goes to UserDetailsServiceImpl . Let's say employee id is 200.
    - Now it calls the session destroy method and I have printed employee id here too. and surprisingly it prints employee id 200. I think this is because it has already executed UserDetailsServiceImpl and updated User object in session.
    - then it goes to Session created. Employee id is again 200.

    4. now logout for second user

    Now, the problem is I never get hold of session of employee id 100. The application flow (spring security) is creating issue, I mean the way it works. How can I avoid this?

    Thank you.
    Last edited by mick; Aug 25th, 2010, 04:20 PM. Reason: Better formatted

  • #2
    I have a few questions. How are you logging in again with another tab in the same browser? Did you go directly to the login page, logout, or clear out your cookies? Normally you would not see a login page again, nor be authenticated as another user until you logout. I'm also not sure how the session gets destroyed. Did you logout? Did it timeout?

    Posting your Spring Security config would help for us to troubleshoot the issue. I'm going to take a stab at it, but I am can't be sure w/out seeing the config and answers to the above questions. My guess is the session is just being reused for the newly authenticated user and thus you never capture an event for it. A few possible solutions are...

    If you went directly to the login page you could prevent this for logged in users. This would ensure you do not reuse the session.

    Turn on session fixation protection. This would probably terminate the previous user's session just before logging in.

    Additionally or instead Capture Spring Security Events to capture the employee id.

    Comment


    • #3
      I am very glad that you took your time to answer my question.

      How are you logging in again with another tab in the same browser? Did you go directly to the login page
      Yes, I can go directly to login page for another tab.

      Normally you would not see a login page again, nor be authenticated as another user until you logout.
      This is the exact behavior I want in my app. If one user is logged in another user should not be able to log in untill first one logs out.

      My applicationContext-security.xml
      Code:
      <global-method-security secured-annotations="enabled" jsr250-annotations="enabled"/>
      
      <http session-fixation-protection="newSession">
           <intercept-url pattern="/images/*" filters="none"/>
           <intercept-url pattern="/dwr/*" filters="none"/>
           .... blah blah....
           <form-login login-page="/login.htm" default-target-url="/home.htm" authentication-failure-url="/login.htm?login_error=true"/>
           <remember-me key="mykey" />
           <logout invalidate-session="true" logout-url="/logout.htm"/>
           <authentication-provider user-service-ref="myUserDetailsService">
      		<password-encoder base64="true" ref="shaPasswordEncoder"></password-encoder>		
      	</authentication-provider>
      </http>
      I'm also not sure how the session gets destroyed. Did you logout? Did it timeout?
      I know this kind of weird but when I log in again in another tab it calls the destroy method for first session without me log out or time out. I have checked with session id. And it starts another session with different session id.

      If you went directly to the login page you could prevent this for logged in users. This would ensure you do not reuse the session.
      I looked at the link you have mentioned. Luke mentioned about writing logic in controller. but should not the "default-target-url" is just enough for automatic redirect in case user is already logged in.

      Turn on session fixation protection. This would probably terminate the previous user's session just before logging in.
      This is already done.

      Additionally or instead Capture Spring Security Events to capture the employee id.
      As I have mentioned in my first post , I have extended HttpSessionEventPublisher class and it has two methods session created and destroy and I am capturing employee id there only.

      So I guess if I somehow manage to restrict two login, I can avoid this problem.

      Thank you again for time.

      Comment


      • #4
        The default-target-url is where Spring Security sends a user after login if a private resource was not requested; it does not impact the application if the login page is directly requested. For example say you went to the url /private/resource which required login. After login Spring Security would send you to /private/resource. However, if you go directly to /login it doesn't know where to send you after you login...this is the default-target-url.

        To implement this the easiest way is to add logic to your login controller or page that checks to see if the user is logged in...if so send them to a default url else does what it use to.

        HTH,

        Comment

        Working...
        X