Announcement Announcement Module
Collapse
No announcement yet.
weird login problem with browser close Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • weird login problem with browser close

    Hi.

    I'm struggling with a weird login problem when closing the browser. I use HTTPS to access a webservice with basic authentication. Acegi does a good job and asks for authentication when accessing the protected url via browser. After authentication I can access several URLs without login - so far everything as expected.

    Now I close every browser instance and restart it. The wierd thing is, that I can access the protected url now WITHOUT login in again! I thought that a cookie would be set and cleaned after the browser closes. So I would expected the login popup again.

    Any hints what that can be?

    I'm using Tomcat 5.5.23 with acegi 1.0.4 and spring 2.0. Browser I used were Firefox 1.5 and IE 6.

    Thanks.
    Veit

  • #2
    In fact, it is exactly the third time when authentication doesn't happen anymore.

    - fresh browserstart
    - authentication is requested - login
    - close browser
    - fresh browserstart
    - authentication is requested - login
    - close browser
    - fresh browserstart
    - authentication is NOT requested!

    I'm using the following filters:

    Code:
    	
                 <bean id="filterChainProxy"
    		class="org.acegisecurity.util.FilterChainProxy">
    		<property name="filterInvocationDefinitionSource">
    			<value>
    				CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
    				PATTERN_TYPE_APACHE_ANT
    				/**=basicProcessingFilter,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor
    			</value>
    		</property>
    	</bean>
    The 3rd time I'll invoke the url, acegi prints the following:

    Code:
    [22.06. 23:14:52,DEBUG,PathBasedFilterInvocationDefinitionMap,]: Converted URL to lowercase, from: '/admin/user'; to: '/admin/user'
    [22.06. 23:14:52,DEBUG,PathBasedFilterInvocationDefinitionMap,]: Candidate is: '/admin/user'; pattern is /**; matched=true
    [22.06. 23:14:52,DEBUG,FilterChainProxy,]: /admin/user at position 1 of 4 in additional filter chain; firing Filter: 'org.acegisecurity.ui.basicauth.BasicProcessingFilter@14177f3'
    [22.06. 23:14:52,DEBUG,BasicProcessingFilter,]: Authorization header: null
    [22.06. 23:14:52,DEBUG,FilterChainProxy,]: /admin/user at position 2 of 4 in additional filter chain; firing Filter: '[email protected]2a2259'
    [22.06. 23:14:52,DEBUG,AnonymousProcessingFilter,]: SecurityContextHolder not populated with anonymous token, as it already contained: '[email protected]85add4: Username: org.acegisecurity.userdetails.User@0: Username: admin; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: ROLE_FRONTEND_ADMIN; Password: [PROTECTED]; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@380f4: RemoteIpAddress: 127.0.0.1; SessionId: 0B6039B4F1F0BBEAC7CA5B8D0F072AFE; Granted Authorities: ROLE_FRONTEND_ADMIN'
    [22.06. 23:14:52,DEBUG,FilterChainProxy,]: /admin/user at position 3 of 4 in additional filter chain; firing Filter: 'org.acegisecurity.ui.ExceptionTranslationFilter@1e81d48'
    [22.06. 23:14:52,DEBUG,FilterChainProxy,]: /admin/user at position 4 of 4 in additional filter chain; firing Filter: '[email protected]'
    [22.06. 23:14:52,DEBUG,PathBasedFilterInvocationDefinitionMap,]: Converted URL to lowercase, from: '/admin/user'; to: '/admin/user'
    [22.06. 23:14:52,DEBUG,PathBasedFilterInvocationDefinitionMap,]: Candidate is: '/admin/user'; pattern is /admin/user*wsdl*; matched=false
    [22.06. 23:14:52,DEBUG,PathBasedFilterInvocationDefinitionMap,]: Candidate is: '/admin/user'; pattern is /admin/**; matched=true
    [22.06. 23:14:52,DEBUG,AbstractSecurityInterceptor,]: Secure object: FilterInvocation: URL: /admin/user; ConfigAttributes: [ROLE_FRONTEND_ADMIN]
    [22.06. 23:14:52,DEBUG,AbstractSecurityInterceptor,]: Previously Authenticated: [email protected]85add4: Username: org.acegisecurity.userdetails.User@0: Username: admin; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: ROLE_FRONTEND_ADMIN; Password: [PROTECTED]; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@380f4: RemoteIpAddress: 127.0.0.1; SessionId: 0B6039B4F1F0BBEAC7CA5B8D0F072AFE; Granted Authorities: ROLE_FRONTEND_ADMIN
    [22.06. 23:14:52,DEBUG,AbstractSecurityInterceptor,]: Authorization successful
    [22.06. 23:14:52,DEBUG,AbstractSecurityInterceptor,]: RunAsManager did not change Authentication object
    [22.06. 23:14:52,DEBUG,FilterChainProxy,]: /admin/user reached end of additional filter chain; proceeding with original chain
    [22.06. 23:14:52,DEBUG,ExceptionTranslationFilter,]: Chain processed normally
    Interesting is the line:

    [22.06. 23:14:52,DEBUG,BasicProcessingFilter,]: Authorization header: null

    and

    [22.06. 23:14:52,DEBUG,AnonymousProcessingFilter,]: SecurityContextHolder not populated with anonymous token, as it already contained: 'org.acegisecurity.providers.UsernamePasswordAuthe nticationToken@485add4: Username: org.acegisecurity.userdetails.User@0: Username: admin; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: ROLE_FRONTEND_ADMIN; Password: [PROTECTED]; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@380f 4: RemoteIpAddress: 127.0.0.1; SessionId: 0B6039B4F1F0BBEAC7CA5B8D0F072AFE; Granted Authorities: ROLE_FRONTEND_ADMIN'

    Where does acegi get the information about the authentication? Seems to be the sessionid of the first request.

    I guess I'm missing something...

    Comment


    • #3
      I found the solution. I missed the httpSessionContextIntegrationFilter. After I added it to the chain everything works as expected.

      Hm, looks like basicAuthentication depends on this. Is there something in the docs that points to that?

      Regards
      Veit

      Comment


      • #4
        I think what has been happening here is that, in the absence of HttpSessionContextIntegrationFilter, you have been left with a valid security context sitting on the handler thread, and by coincidence (likely because you only had one user of the system at the time) you got allocated the same handler thread the second time round.

        HttpSessionContextIntegrationFilter will always clear the thread local context at the end of an invocation and it is essential that something does this, otherwise users would potentially be making invocations using other people's credentials. So in this sense, HttpSessionContextIntegrationFilter is essential (or an equivalent filter is needed to make sure the context is cleared).

        A similar situation arises using RMI, where we have ContextPropagatingRemoteInvocation:

        http://acegisecurity.org/multiprojec...ation.html#103

        which does the same job.

        Note that HttpSessionContextIntegrationFilter won't normally create a session unless you ask it to - it will just provide integration if one exists. So you can use it just to make sure that the context is cleared, without worrying about having unnecessary sessions hanging around.

        Comment

        Working...
        X