Spring Security
  1. Spring Security
  2. SEC-1019

Login via https didn't redirect correctly to http page

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 2.0.4
    • Fix Version/s: 3.0.0 M1
    • Component/s: Core
    • Labels:
      None
    • Environment:
      Windows XP, IE 6 SP3

      Description

      When i login to application via https login.jsp and redirects to index.jsp witch could be accessed via http only then it forwards me back to login.jsp
      See configuration below:

      <sec:http auto-config="true">
      <sec:intercept-url pattern="/login.jsp" access="IS_AUTHENTICATED_ANONYMOUSLY" requires-channel="https"/>
      <sec:intercept-url pattern="/index.jsp" access="ROLE_PLAYER" requires-channel="http"/>
      <sec:form-login login-page="/login.jsp" default-target-url="/index.jsp" />
      </sec:http>

      I solved this by my implementation of org.springframework.security.ui.TargetUrlResolverImpl. Bug occurs because of in redirection to http link Spring Security framework did't define jsessionid.

      1. ExTargetUrlResolverImpl.java
        0.7 kB
        Nikita Koksharov
      2. security-context.xml
        2 kB
        Nikita Koksharov

        Activity

        Hide
        Nikita Koksharov added a comment -

        I think my functionality should be implemented in org.springframework.security.ui.AbstractProcessingFilter.determineTargetUrl method

        Show
        Nikita Koksharov added a comment - I think my functionality should be implemented in org.springframework.security.ui.AbstractProcessingFilter.determineTargetUrl method
        Hide
        Luke Taylor added a comment -

        We use the HttpServletResponse.encodeRedirectURL method which should include the JSESSIONID in the URL if necessary.

        Show
        Luke Taylor added a comment - We use the HttpServletResponse.encodeRedirectURL method which should include the JSESSIONID in the URL if necessary.
        Hide
        Nikita Koksharov added a comment -

        encodeRedirectURL not including jsessionid then we going from https to http channel, it's not mentioned in documentation. So i think it would be right to fix this in framework.

        Show
        Nikita Koksharov added a comment - encodeRedirectURL not including jsessionid then we going from https to http channel, it's not mentioned in documentation. So i think it would be right to fix this in framework.
        Hide
        Luke Taylor added a comment -

        The JSESSIONID value is entirely handled by the container and isn't something we should be choosing to explicitly add to URLs ourselves. If you start in HTTPS and change to HTTP then the container may choose to ditch the session information entirely (as Tomcat does - see the FAQ on this issue).

        Show
        Luke Taylor added a comment - The JSESSIONID value is entirely handled by the container and isn't something we should be choosing to explicitly add to URLs ourselves. If you start in HTTPS and change to HTTP then the container may choose to ditch the session information entirely (as Tomcat does - see the FAQ on this issue).
        Hide
        Luke Taylor added a comment -

        Almost certainly just normal secure cookie behaviour, therefore not a bug.

        Show
        Luke Taylor added a comment - Almost certainly just normal secure cookie behaviour, therefore not a bug.
        Hide
        Nikita Koksharov added a comment -

        So what should i do? Always implement my resolution of this problem in my projects?

        Show
        Nikita Koksharov added a comment - So what should i do? Always implement my resolution of this problem in my projects?
        Hide
        Ryan Donahue added a comment -

        As implemented, the following scenario cannot work on Tomcat when the browser has disabled cookies:
        (1) Start session over http
        (2) Request resource over http that requires https
        (3) Redirect to login over https
        (4) After successful login, redirect back to original resource over http

        This scenario is discussed often in Spring Security documentation and should be supported.

        As Luke pointed out, encodeRedirectURL is not adding the jsessionid. However, this is because it is being passed an absolute URL for which encodeRedirectURL cannot determine if it points to somewhere within the current web application (see description of isEncodeable at http://tomcat.apache.org/tomcat-5.5-doc/catalina/docs/api/org/apache/catalina/connector/Response.html#isEncodeable(java.lang.String) ).

        I was able to verify this by writing a custom AuthenticationProcessingFilter that constructed the URL relative from the context first, then applied encodeRedirectURL to the relative URL (which does successfully add the session id), and finally constructing the absolute URL from the encoded relative URL.

        I wonder if this worked at one time when the URL was relative, but broke when the URL was changed to absolute (see 2nd to last paragraph in section 7.2 of the Spring Security Reference Documentation which notes a change to absolute because of an IE6 bug, http://static.springframework.org/spring-security/site/reference/html/channel-security.html#channel-security-config ).

        Show
        Ryan Donahue added a comment - As implemented, the following scenario cannot work on Tomcat when the browser has disabled cookies: (1) Start session over http (2) Request resource over http that requires https (3) Redirect to login over https (4) After successful login, redirect back to original resource over http This scenario is discussed often in Spring Security documentation and should be supported. As Luke pointed out, encodeRedirectURL is not adding the jsessionid. However, this is because it is being passed an absolute URL for which encodeRedirectURL cannot determine if it points to somewhere within the current web application (see description of isEncodeable at http://tomcat.apache.org/tomcat-5.5-doc/catalina/docs/api/org/apache/catalina/connector/Response.html#isEncodeable(java.lang.String ) ). I was able to verify this by writing a custom AuthenticationProcessingFilter that constructed the URL relative from the context first, then applied encodeRedirectURL to the relative URL (which does successfully add the session id), and finally constructing the absolute URL from the encoded relative URL. I wonder if this worked at one time when the URL was relative, but broke when the URL was changed to absolute (see 2nd to last paragraph in section 7.2 of the Spring Security Reference Documentation which notes a change to absolute because of an IE6 bug, http://static.springframework.org/spring-security/site/reference/html/channel-security.html#channel-security-config ).

          People

          • Assignee:
            Luke Taylor
            Reporter:
            Nikita Koksharov
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: