CODEWITHSUNDEEP
servletsssljetty
JFK
JFK

Reputation: 1677

Does Jetty support SessionTrackingMode.SSL

SessionTrackingMode allows you to specify that the Servlet Session is tied to an SSL Session. Tomcat supports this Tomcat SSL HOW-TO. Is there any mechanism to achieve this in Jetty?

For example if I do the following in my Servlet init;

@WebServlet(urlPatterns ={ "/session_test" })

public class SessionTestServlet extends HttpServlet {

private static final SessionTrackingMode[] modeArray = { SessionTrackingMode.SSL };
private static final Set<SessionTrackingMode> SESSION_TRACKING_MODES = new HashSet<>(Arrays.asList(modeArray));

@Override
public void init(ServletConfig config) throws ServletException {
    super.init(config);
    config.getServletContext().setSessionTrackingModes(SESSION_TRACKING_MODES);
}

then no session is created.

Upvotes: 2

Views: 493

Answers (1)

Joakim Erdfelt
Joakim Erdfelt

Reputation: 49462

There appears to be no support for SessionTrackingMode.SSL in Jetty.

Just opened bug about it (as you are officially the very first person to ever ask about this functionality of the servlet spec)

https://github.com/eclipse/jetty.project/issues/161

Would be curious to know how this will work in the future, with HTTP/2 you don't have new SSL connections with each subsequent request, they'll just be tunneled within the same ALPN layer.

Update: 2014-Oct-2

To address Session ID Hijacking, there is a feature implemented in Jetty 9 that will change the session id after authentication. Bug-392247

This does a nice job in preventing hijacking of authenticated sessions by malicious 3rd parties. (Just start using SSL from your login forward)

Now, some background, in versions of Jetty prior to Jetty 9 (aka Servlet 3.1), we would create a new session object and copy over the old session data. This meant that we would also trigger the registered session listeners of this change.

This is no longer true with Jetty 9, as the new Servlet 3.1 introduced a new method HttpServletRequest.changeSessionId(), which a user can also call to force change the sessionId, and also HttpServletRequest.login(), which a user can call to programmatically log in. This is also accompanied with a requirement that if a session existed before those two calls (session object before == session object after), then there is no listener to be fired. This means we just change the sessionId and not the object.

What does this mean for Session ID Hijacking, nothing really, but its useful to know that these methods exist and what using them represents. :)

Upvotes: 2

Related Questions