Announcement Announcement Module
Collapse
No announcement yet.
Login Failure when Tomcat reuses session and ThreadLocal Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Login Failure when Tomcat reuses session and ThreadLocal

    Hi Ben and Community,

    I have now almost successfully integrated acegi into my webapp. Wasn't that difficult. But now I'm facing a weird problem: The first two users can login, all others are continuously redirected to the login page despite successful authentication. And after some hours of debugging I believe I've found the problem.

    I'm using acegi 0.6:
    The first two login attempts are provided new instances of the Threadlocal contextholder. I guess Tomcat creates two session instances by default. The third session apparently reuses an existing session instance, thus the context will be pre-populated with an existing but empty context (remainder from last attempt). Now the logic, after the authentication (j_acegi_security_check) returns from chain.doFilter(), implies that in the integration filter this context is recognized as valid and the session is populated with this empty authentication. Thus after redirection to the target URL no valid authentication record is found in the session and the SecurityInterceptor continues to redirect to the logon page.

    The solution would possibly be to
    a) invalidate the Context by removing it entirely
    b) check also the existence of a valid auth before populating the session
    c) don't check at all after returning from j_acegi_security_check

    I'll try each and let you know. But you may want to comment on the best solution?

    But perhaps...I can hardly believe this problem has gone unnoticed. Am I missing something?

    Thanks and best regards

  • #2
    I too am wondering if there is actually a problem, as Acegi Security is now so widely deployed something so fundamental surely would have been noticed in the last 10 months. Would you mind posting your web.xml, as I wouldn't be surprised if a filter is missing. The HttpSessionIntegrationFilter (or AutoIntegrationFilter) is responsible for Contextholder invalidation. Also don't forget to try release 0.7.0, so we can talk about the same line number etc.

    Comment

    Working...
    X