Nikita Koksharov(Migrated from SEC-1019) said:
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:
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.
Nikita Koksharov said:
I think my functionality should be implemented in org.springframework.security.ui.AbstractProcessingFilter.determineTargetUrl method
Luke Taylor said:
We use the HttpServletResponse.encodeRedirectURL method which should include the JSESSIONID in the URL if necessary.
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.
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).
Almost certainly just normal secure cookie behaviour, therefore not a bug.
So what should i do? Always implement my resolution of this problem in my projects?
Ryan Donahue said:
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 ).