How can I prevent spring-security from appending ;jsessionid=XXX to login redirects?

问题

When an unauthenticated client requests a URL that requires a non-anonymous access level as defined in security-config.xml, spring security sends an HTTP redirect to our login page (e.g. /login). That's fine.

The issue is that absent an existing session (identified by a cookie provided in the client's request), spring-security issues a redirect that also specifies the client's new session in the URL, e.g. /login;jsessionid=8o7pglapojus.

Many containers support this (apparently it works fine in tomcat?), but it appears that Jetty (which is what we're using right now) does not -- the redirected URL comes through to our URL router completely intact (including the jsessionid "parameter"), and the named session is not associated with the /login request by jetty/spring-security (i.e. a totally new session ID is provided in the Set-Cookie header of the response to the /login request).

We can work around this by matching /login.* in our routes, but I'm curious if there's any way to prevent the emission of the session id in the authentication redirect to begin with.

回答1:

In Spring Security 3.0.0 M1 or newer you could set disable-url-rewriting="true" in the <http> namespace. See if that helps. Also see this feature request.

回答2:

Now it looks like this.

<security:http auto-config="false" use-expressions="true" disable-url-rewriting="true">

After this, your application will be unable to perform stateful jobs properly.

回答3:

Since you are using jetty, simply add the following context-param tag in your web.xml,

<!-- Disables appending JSESSSIONID in browser address bar/requests -->
<context-param>
    <param-name>org.eclipse.jetty.servlet.SessionIdPathParameterName</param-name>
    <param-value>none</param-value>
</context-param>

Refer: Session Management - Jetty Doc

回答4:

@ahmet alp balkan:

seamframework provide a better solution than randomcoders. http://seamframework.org/Documentation/RemovingJSESSIONIDFromYourURLsAndFixingScache

@BalusC:

If developer used spring security's FilterChainProxy to implement the securtiy feature,just not using http namespace.

Then we couldn't find a way to add disable-url-rewriting without try to add a custom filter to filter chain,or insert a independent filter to web.xml.

回答5:

Another solution is here (for those Spring Security at all i.e. myself)

http://randomcoder.com/articles/jsessionid-considered-harmful

Creates a Servlet filter wrapper and manages handles this.

回答6:

Here is how I solved this issue...

the scenario was I had a few session less and security="none" pages and upon re-direct post submission - redirect url used to get appended with ;Jsessionid= in url - ofcourse leading to errors...

Also, i couldn't add disable-url-rewriting="true" also didn't work.

What worked for me if below code in submission on form-submission

HttpSession session = request.getSession();
if (session != null) session.invalidate();

this made sure there is no active session - which ensures spring on redirect post submission doesn't need to carry session information, hence no need to add JSESSION to the url.

This was of course needed my specific case.. and cannot be used as generic solution for the whole application. Let me know if this helps you.

回答7:

I already added an answer to this for specific use cases - here are multiple ways you can tackle it (summarizing my discovery journey and experiments)

@ overall level - ensures no url rewriting level

<sec:http pattern="/<your url pattern>/**" disable-url-rewriting="true"

ensures no session information is not needed, hence no need to append JSESSSIONID

<%@ page session="false" %>

@ Controller level - before directing to page/url invalidate the session. No Session > No Session Information TO Carry > No appending JSESSIONID

HttpSession session = request.getSession(); if (session != null) session.invalidate();

These solutions are specific to spring security. There are other solutions which can be done @ Tomcat level

changing session tracking to COOKIE, session information already with browser cookie > No need to pass information in url > No appending JSESSIONID [doesn't work where cookies are not allowed, I faced the issue with Safari/Opera Browsers + Chrome with strict third party cookie settings]