Spring Security
  1. Spring Security
  2. SEC-1656

Manually setting an authentication on the current SecurityContext fails due to session ID change after request has been sent to browser

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 3.0.5
    • Fix Version/s: 3.1.0.RC1
    • Component/s: Web
    • Labels:
      None

      Description

      Problem Description
      =================
      In a SpringMVC app, when manually setting the authentication via the SecurityContextHolder (as shown below)...

      SecurityContextHolder.getContext().setAuthentication(authenticationToken);

      The authentication will be lost after the current request has completed processing. This is what happens:

      1) The security context is updated with the authenticationToken successfully, for the remainder of this request everything is as expected
      2) At the end of this request (after the response has been flushed to the client) the HttpSessionSecurityContextRepository will attempt to save the security context to the HttpSession.
      3) The above step will trigger a new HttpSession object as the previous one was found to be null, this will trigger a new SessionID creation.
      4) Since the above SessionID was created after the response was flushed to the browser it will not update the SessionID cookie
      5) On the next request the previous SessionID will be sent and the new security context is lost.

      Use Case:
      ========
      A create account form controller manually logs in a user after the new account was created so the user doesn't have to go through the normal form login (which is processed by standard Spring Security Authentication).

      Proposed solution:
      ==================
      A call to:
      SecurityContextHolder.getContext().setAuthentication(authenticationToken);

      should (somehow) ensure that a session object exists for storing the security context to BEFORE the end of the request is reached.

      Log snippets demonstrating the situation
      ==================================
      153321 [qtp863455443-20 - /createaccount] DEBUG org.eclipse.jetty.util.log - REQUEST /createaccount on org.eclipse.jetty.server.nio.SelectChannelConnector$3@5a32835b
      153321 [qtp863455443-20 - /createaccount] DEBUG org.eclipse.jetty.util.log - Got Session ID wq3vojg45nc31nc0plpix60ly from cookie
      153321 [qtp863455443-20 - /createaccount] DEBUG org.eclipse.jetty.util.log - sessionManager=org.eclipse.jetty.server.session.HashSessionManager@79f7896f
      153321 [qtp863455443-20 - /createaccount] DEBUG org.eclipse.jetty.util.log - session=null

      153323 [qtp863455443-20 - /createaccount] DEBUG org.springframework.security.web.context.HttpSessionSecurityContextRepository - No HttpSession currently exists
      153323 [qtp863455443-20 - /createaccount] DEBUG org.springframework.security.web.context.HttpSessionSecurityContextRepository - No SecurityContext was available from the HttpSession: null. A new one will be created.

      153323 [qtp863455443-20 - /createaccount] DEBUG org.springframework.security.web.authentication.AnonymousAuthenticationFilter - Populated SecurityContextHolder with anonymous token: 'org.springframework.security.authentication.AnonymousAuthenticationToken@9055e4a6: Principal: anonymousUser; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@957e: RemoteIpAddress: 127.0.0.1; SessionId: null; Granted Authorities: ROLE_ANONYMOUS'
      153323 [qtp863455443-20 - /createaccount] DEBUG org.springframework.security.web.FilterChainProxy - /createaccount at position 7 of 9 in additional filter chain; firing Filter: 'SessionManagementFilter'
      153324 [qtp863455443-20 - /createaccount] DEBUG org.springframework.security.web.session.SessionManagementFilter - Requested session IDwq3vojg45nc31nc0plpix60ly is invalid.

      154463 [qtp863455443-20 - /createaccount] DEBUG org.springframework.security.web.context.HttpSessionSecurityContextRepository - HttpSession being created as SecurityContext is non-default
      154464 [qtp863455443-20 - /createaccount] DEBUG org.eclipse.jetty.util.log - new session & id 96zm3w2a9pr01tcxiuhj4ds1j 96zm3w2a9pr01tcxiuhj4ds1j
      154464 [qtp863455443-20 - /createaccount] DEBUG org.springframework.security.web.context.HttpSessionSecurityContextRepository - SecurityContext stored to HttpSession: 'org.springframework.security.core.context.SecurityContextImpl@c1b8beb7: Authentication: com.prepayproxy.spring.UsernamePasswordWithAttributesAuthenticationToken@c1b8beb7: Principal: com.prepayproxy.servicelayer.SpringAuthorizationService$UserDetailsWithAttributesImpl@4c97ed28; Credentials: [PROTECTED]; Authenticated: true; Details: null; Granted Authorities: ROLE_USER'

      166583 [qtp863455443-17 - /] DEBUG org.eclipse.jetty.util.log - Got Session ID wq3vojg45nc31nc0plpix60ly from cookie
      166584 [qtp863455443-17 - /] DEBUG org.eclipse.jetty.util.log - sessionManager=org.eclipse.jetty.server.session.HashSessionManager@79f7896f
      166584 [qtp863455443-17 - /] DEBUG org.eclipse.jetty.util.log - session=null

      166585 [qtp863455443-17 - /] DEBUG org.springframework.security.web.context.HttpSessionSecurityContextRepository - No HttpSession currently exists
      166585 [qtp863455443-17 - /] DEBUG org.springframework.security.web.context.HttpSessionSecurityContextRepository - No SecurityContext was available from the HttpSession: null. A new one will be created.

      166586 [qtp863455443-17 - /] DEBUG org.springframework.security.web.authentication.AnonymousAuthenticationFilter - Populated SecurityContextHolder with anonymous token: 'org.springframework.security.authentication.AnonymousAuthenticationToken@9055e4a6: Principal: anonymousUser; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@957e: RemoteIpAddress: 127.0.0.1; SessionId: null; Granted Authorities: ROLE_ANONYMOUS'
      166586 [qtp863455443-17 - /] DEBUG org.springframework.security.web.FilterChainProxy - / at position 7 of 9 in additional filter chain; firing Filter: 'SessionManagementFilter'
      166586 [qtp863455443-17 - /] DEBUG org.springframework.security.web.session.SessionManagementFilter - Requested session IDwq3vojg45nc31nc0plpix60ly is invalid.

      166620 [qtp863455443-17 - /] DEBUG org.springframework.security.web.context.HttpSessionSecurityContextRepository - SecurityContext is empty or anonymous - context will not be stored in HttpSession.

      180971 [qtp863455443-20 - /postlogin] DEBUG org.eclipse.jetty.util.log - Got Session ID wq3vojg45nc31nc0plpix60ly from cookie
      180971 [qtp863455443-20 - /postlogin] DEBUG org.eclipse.jetty.util.log - sessionManager=org.eclipse.jetty.server.session.HashSessionManager@79f7896f
      180971 [qtp863455443-20 - /postlogin] DEBUG org.eclipse.jetty.util.log - session=null

      180974 [qtp863455443-20 - /postlogin] DEBUG org.springframework.security.web.context.HttpSessionSecurityContextRepository - No HttpSession currently exists
      180974 [qtp863455443-20 - /postlogin] DEBUG org.springframework.security.web.context.HttpSessionSecurityContextRepository - No SecurityContext was available from the HttpSession: null. A new one will be created.

      180975 [qtp863455443-20 - /postlogin] DEBUG org.eclipse.jetty.util.log - new session & id 17zsa0kugrglijjggbrvzfgpg 17zsa0kugrglijjggbrvzfgpg

      180995 [qtp863455443-20 - /postlogin] DEBUG org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter - Authentication success. Updating SecurityContextHolder to contain: com.prepayproxy.spring.UsernamePasswordWithAttributesAuthenticationToken@d3c4cac3: Principal: com.prepayproxy.servicelayer.SpringAuthorizationService$UserDetailsWithAttributesImpl@5ee819a8; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@380f4: RemoteIpAddress: 127.0.0.1; SessionId: 17zsa0kugrglijjggbrvzfgpg; Granted Authorities: ROLE_USER

      180996 [qtp863455443-20 - /postlogin] DEBUG org.springframework.security.web.context.HttpSessionSecurityContextRepository - SecurityContext stored to HttpSession: 'org.springframework.security.core.context.SecurityContextImpl@d3c4cac3: Authentication: com.prepayproxy.spring.UsernamePasswordWithAttributesAuthenticationToken@d3c4cac3: Principal: com.prepayproxy.servicelayer.SpringAuthorizationService$UserDetailsWithAttributesImpl@5ee819a8; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@380f4: RemoteIpAddress: 127.0.0.1; SessionId: 17zsa0kugrglijjggbrvzfgpg; Granted Authorities: ROLE_USER'

      181050 [qtp863455443-16 - /myaccount] DEBUG org.eclipse.jetty.util.log - Got Session ID 17zsa0kugrglijjggbrvzfgpg from cookie
      181050 [qtp863455443-16 - /myaccount] DEBUG org.eclipse.jetty.util.log - sessionManager=org.eclipse.jetty.server.session.HashSessionManager@79f7896f
      181050 [qtp863455443-16 - /myaccount] DEBUG org.eclipse.jetty.util.log - session=org.eclipse.jetty.server.session.HashSessionManager$HashedSession:17zsa0kugrglijjggbrvzfgpg@1385660009

      181052 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.context.HttpSessionSecurityContextRepository - Obtained a valid SecurityContext from SPRING_SECURITY_CONTEXT: 'org.springframework.security.core.context.SecurityContextImpl@d3c4cac3: Authentication: com.prepayproxy.spring.UsernamePasswordWithAttributesAuthenticationToken@d3c4cac3: Principal: com.prepayproxy.servicelayer.SpringAuthorizationService$UserDetailsWithAttributesImpl@5ee819a8; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@380f4: RemoteIpAddress: 127.0.0.1; SessionId: 17zsa0kugrglijjggbrvzfgpg; Granted Authorities: ROLE_USER'

      181053 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.authentication.AnonymousAuthenticationFilter - SecurityContextHolder not populated with anonymous token, as it already contained: 'com.prepayproxy.spring.UsernamePasswordWithAttributesAuthenticationToken@d3c4cac3: Principal: com.prepayproxy.servicelayer.SpringAuthorizationService$UserDetailsWithAttributesImpl@5ee819a8; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@380f4: RemoteIpAddress: 127.0.0.1; SessionId: 17zsa0kugrglijjggbrvzfgpg; Granted Authorities: ROLE_USER'
      181053 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.FilterChainProxy - /myaccount at position 7 of 9 in additional filter chain; firing Filter: 'SessionManagementFilter'

      192700 [qtp863455443-20 - /] DEBUG org.eclipse.jetty.util.log - Got Session ID 17zsa0kugrglijjggbrvzfgpg from cookie
      192700 [qtp863455443-20 - /] DEBUG org.eclipse.jetty.util.log - sessionManager=org.eclipse.jetty.server.session.HashSessionManager@79f7896f
      192701 [qtp863455443-20 - /] DEBUG org.eclipse.jetty.util.log - session=org.eclipse.jetty.server.session.HashSessionManager$HashedSession:17zsa0kugrglijjggbrvzfgpg@1385660009

      192703 [qtp863455443-20 - /] DEBUG org.springframework.security.web.context.HttpSessionSecurityContextRepository - Obtained a valid SecurityContext from SPRING_SECURITY_CONTEXT: 'org.springframework.security.core.context.SecurityContextImpl@d3c4cac3: Authentication: com.prepayproxy.spring.UsernamePasswordWithAttributesAuthenticationToken@d3c4cac3: Principal: com.prepayproxy.servicelayer.SpringAuthorizationService$UserDetailsWithAttributesImpl@5ee819a8; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@380f4: RemoteIpAddress: 127.0.0.1; SessionId: 17zsa0kugrglijjggbrvzfgpg; Granted Authorities: ROLE_USER'

      192704 [qtp863455443-20 - /] DEBUG org.springframework.security.web.authentication.AnonymousAuthenticationFilter - SecurityContextHolder not populated with anonymous token, as it already contained: 'com.prepayproxy.spring.UsernamePasswordWithAttributesAuthenticationToken@d3c4cac3: Principal: com.prepayproxy.servicelayer.SpringAuthorizationService$UserDetailsWithAttributesImpl@5ee819a8; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@380f4: RemoteIpAddress: 127.0.0.1; SessionId: 17zsa0kugrglijjggbrvzfgpg; Granted Authorities: ROLE_USER'
      192704 [qtp863455443-20 - /] DEBUG org.springframework.security.web.FilterChainProxy - / at position 7 of 9 in additional filter chain; firing Filter: 'SessionManagementFilter'

        Activity

        Hide
        Luke Taylor added a comment -

        The SecurityContextHolder can't ensure that a session exists as it has no knowledge of the fact that it is operating in a web environment. It is also possible that another implementation of SecurityContextRepository is being used.

        Why can't you just ensure there is a session in your app, by calling request.getSession() as part of your login code?

        Show
        Luke Taylor added a comment - The SecurityContextHolder can't ensure that a session exists as it has no knowledge of the fact that it is operating in a web environment. It is also possible that another implementation of SecurityContextRepository is being used. Why can't you just ensure there is a session in your app, by calling request.getSession() as part of your login code?
        Hide
        Luke Taylor added a comment -

        Another option is to make sure that the login response is not committed before the filter chain completes (by ensuring that the buffer is large enough to accomodate it). Or simply use a redirect, as we normally do, which is automatically catered for in the response wrapper.

        Show
        Luke Taylor added a comment - Another option is to make sure that the login response is not committed before the filter chain completes (by ensuring that the buffer is large enough to accomodate it). Or simply use a redirect, as we normally do, which is automatically catered for in the response wrapper.
        Hide
        David Parks added a comment -

        Makes sense that the SecurityContextHolder can't be aware of the session.

        I can of course make sure a session object exists (this was a quick temporary workaround I employed). But I posted this because it's not obvious that this is necessary and likely to bite others in the future. The spring security docs seem to suggest that this is feasible (at least they tell you that you can manually set the Authentication, which is why I tried this route for the initial login at account creation time).

        An internal forward to the login process sounds like the most logical approach, however I have to figure out how to then forward back to the account creation page rather than on to the default accounts page that users should normally be forwarded to on login (I didn't think of this approach before).

        My thought though, in posting this, was that perhaps one of the web based filters that get added by default with the form login configuration. I noticed these logs when I was debugging. Perhaps one of these filters (since they occur before the page is rendered) should be responsible for ensuring that an HTTP session object exists.

        This is not my area of expertise, I'm just a user of this framework, so this is just a thought that came from debugging. If I'm off-base feel free to say so. I'm just exploring options that would be best to eliminate the source of the issue so others can make use of this functionality without worrying about odd-ball dependencies like this.

        181051 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.FilterChainProxy - /myaccount at position 1 of 9 in additional filter chain; firing Filter: 'SecurityContextPersistenceFilter'
        181052 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.context.HttpSessionSecurityContextRepository - Obtained a valid SecurityContext from SPRING_SECURITY_CONTEXT: 'org.springframework.security.core.context.SecurityContextImpl@d3c4cac3: Authentication: com.prepayproxy.spring.UsernamePasswordWithAttributesAuthenticationToken@d3c4cac3: Principal: com.prepayproxy.servicelayer.SpringAuthorizationService$UserDetailsWithAttributesImpl@5ee819a8; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@380f4: RemoteIpAddress: 127.0.0.1; SessionId: 17zsa0kugrglijjggbrvzfgpg; Granted Authorities: ROLE_USER'
        181052 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.FilterChainProxy - /myaccount at position 2 of 9 in additional filter chain; firing Filter: 'LogoutFilter'
        181052 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.FilterChainProxy - /myaccount at position 3 of 9 in additional filter chain; firing Filter: 'UsernamePasswordAuthenticationFilter'
        181052 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.FilterChainProxy - /myaccount at position 4 of 9 in additional filter chain; firing Filter: 'RequestCacheAwareFilter'
        181052 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.FilterChainProxy - /myaccount at position 5 of 9 in additional filter chain; firing Filter: 'SecurityContextHolderAwareRequestFilter'
        181052 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.FilterChainProxy - /myaccount at position 6 of 9 in additional filter chain; firing Filter: 'AnonymousAuthenticationFilter'
        181053 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.authentication.AnonymousAuthenticationFilter - SecurityContextHolder not populated with anonymous token, as it already contained: 'com.prepayproxy.spring.UsernamePasswordWithAttributesAuthenticationToken@d3c4cac3: Principal: com.prepayproxy.servicelayer.SpringAuthorizationService$UserDetailsWithAttributesImpl@5ee819a8; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@380f4: RemoteIpAddress: 127.0.0.1; SessionId: 17zsa0kugrglijjggbrvzfgpg; Granted Authorities: ROLE_USER'
        181053 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.FilterChainProxy - /myaccount at position 7 of 9 in additional filter chain; firing Filter: 'SessionManagementFilter'
        181053 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.FilterChainProxy - /myaccount at position 8 of 9 in additional filter chain; firing Filter: 'ExceptionTranslationFilter'
        181053 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.FilterChainProxy - /myaccount at position 9 of 9 in additional filter chain; firing Filter: 'FilterSecurityInterceptor'

        Show
        David Parks added a comment - Makes sense that the SecurityContextHolder can't be aware of the session. I can of course make sure a session object exists (this was a quick temporary workaround I employed). But I posted this because it's not obvious that this is necessary and likely to bite others in the future. The spring security docs seem to suggest that this is feasible (at least they tell you that you can manually set the Authentication, which is why I tried this route for the initial login at account creation time). An internal forward to the login process sounds like the most logical approach, however I have to figure out how to then forward back to the account creation page rather than on to the default accounts page that users should normally be forwarded to on login (I didn't think of this approach before). My thought though, in posting this, was that perhaps one of the web based filters that get added by default with the form login configuration. I noticed these logs when I was debugging. Perhaps one of these filters (since they occur before the page is rendered) should be responsible for ensuring that an HTTP session object exists. This is not my area of expertise, I'm just a user of this framework, so this is just a thought that came from debugging. If I'm off-base feel free to say so. I'm just exploring options that would be best to eliminate the source of the issue so others can make use of this functionality without worrying about odd-ball dependencies like this. 181051 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.FilterChainProxy - /myaccount at position 1 of 9 in additional filter chain; firing Filter: 'SecurityContextPersistenceFilter' 181052 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.context.HttpSessionSecurityContextRepository - Obtained a valid SecurityContext from SPRING_SECURITY_CONTEXT: 'org.springframework.security.core.context.SecurityContextImpl@d3c4cac3: Authentication: com.prepayproxy.spring.UsernamePasswordWithAttributesAuthenticationToken@d3c4cac3: Principal: com.prepayproxy.servicelayer.SpringAuthorizationService$UserDetailsWithAttributesImpl@5ee819a8; Credentials: [PROTECTED] ; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@380f4: RemoteIpAddress: 127.0.0.1; SessionId: 17zsa0kugrglijjggbrvzfgpg; Granted Authorities: ROLE_USER' 181052 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.FilterChainProxy - /myaccount at position 2 of 9 in additional filter chain; firing Filter: 'LogoutFilter' 181052 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.FilterChainProxy - /myaccount at position 3 of 9 in additional filter chain; firing Filter: 'UsernamePasswordAuthenticationFilter' 181052 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.FilterChainProxy - /myaccount at position 4 of 9 in additional filter chain; firing Filter: 'RequestCacheAwareFilter' 181052 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.FilterChainProxy - /myaccount at position 5 of 9 in additional filter chain; firing Filter: 'SecurityContextHolderAwareRequestFilter' 181052 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.FilterChainProxy - /myaccount at position 6 of 9 in additional filter chain; firing Filter: 'AnonymousAuthenticationFilter' 181053 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.authentication.AnonymousAuthenticationFilter - SecurityContextHolder not populated with anonymous token, as it already contained: 'com.prepayproxy.spring.UsernamePasswordWithAttributesAuthenticationToken@d3c4cac3: Principal: com.prepayproxy.servicelayer.SpringAuthorizationService$UserDetailsWithAttributesImpl@5ee819a8; Credentials: [PROTECTED] ; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@380f4: RemoteIpAddress: 127.0.0.1; SessionId: 17zsa0kugrglijjggbrvzfgpg; Granted Authorities: ROLE_USER' 181053 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.FilterChainProxy - /myaccount at position 7 of 9 in additional filter chain; firing Filter: 'SessionManagementFilter' 181053 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.FilterChainProxy - /myaccount at position 8 of 9 in additional filter chain; firing Filter: 'ExceptionTranslationFilter' 181053 [qtp863455443-16 - /myaccount] DEBUG org.springframework.security.web.FilterChainProxy - /myaccount at position 9 of 9 in additional filter chain; firing Filter: 'FilterSecurityInterceptor'
        Hide
        Luke Taylor added a comment -

        In a normal configuration, the filters are used to authenticate the user and will normally create a session in the process (or can be configured to do so). Either the AbstractAuthenticationFilter will create one or the SessionAuthenticationStrategy can be configured to do so. If you are performing the authentication in an MVC controller then there's nothing the security filters can do at that point, though if you use a redirect after authenticating (rather than rendering a response), then the context will be immediately saved. It is really up to you since no part of Spring Security's web code really gets a say otherwise, until the response has been committed, by which time it is too late to create a new session.

        Show
        Luke Taylor added a comment - In a normal configuration, the filters are used to authenticate the user and will normally create a session in the process (or can be configured to do so). Either the AbstractAuthenticationFilter will create one or the SessionAuthenticationStrategy can be configured to do so. If you are performing the authentication in an MVC controller then there's nothing the security filters can do at that point, though if you use a redirect after authenticating (rather than rendering a response), then the context will be immediately saved. It is really up to you since no part of Spring Security's web code really gets a say otherwise, until the response has been committed, by which time it is too late to create a new session.
        Hide
        David Parks added a comment -

        Using the redirect: directive works perfectly, this is clearly the ideal solution.

        I did note that the documentation (section 5.3.2 specifically) states that you can set this manually in a controller, which is what lead me to this problem. I will post an update for the documentation to call attention to this little issue that can arise when setting the authentication manually from a controller.

        Show
        David Parks added a comment - Using the redirect: directive works perfectly, this is clearly the ideal solution. I did note that the documentation (section 5.3.2 specifically) states that you can set this manually in a controller, which is what lead me to this problem. I will post an update for the documentation to call attention to this little issue that can arise when setting the authentication manually from a controller.

          People

          • Assignee:
            Luke Taylor
            Reporter:
            David Parks
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: