[11.0.x] Invalidate session doesn't remove it from jetty cache

[nicolasbron]

I have recently created a jetty issue as I thought it's a jetty issue. When I invalidate the session it still resides in the sessionCache of AbstractSessionManager (jetty). And due to that the cookie JSESSIONID is never regenerated. We are reusing session id that was previously invalidated.

Please check issue:
jetty/jetty.project#13662

However I did test it and it looks as it is not enough and old session id is still kept.

[grgrzybek]

Thanks for checking this. I felt there's something missing in this session manipulation...
I'll handle it together with #2110

[janbartel]

@grgrzybek what's the reason behind the extensive recoding of the jetty classes? The session stuff is really a nightmare to get right, so it would be great if you could reuse the majority of the code. Is there some lack of extensibility or pluggability that jetty is missing that would enable you to reuse more?

[grgrzybek]

Thanks @janbartel for your comment! I appreciate it.

The need for some hacking comes from OSGi CMPN Whiteboard Service specification:

That Http Sessions are not shared amongst servlets registered with different ServletContextHelpers. That is, HttpRequest.getSession() calls must provide different sessions per associated ServletContextHelper

The problem is that JSESSIONID cookie for sessions are kind of scoped to the ServletContext - in Jetty, there's one SessionHandler (and manager, and id generator, and cache ...) per ContextHandler.

From user (browser) perspective, there's also a single web application - with specific context path.

But in between there's OSGi implementation of Whiteboard specification and the point is that different bundles may register servlets with different ServletContextHelpers associated into the same ServletContext. path cookie attribute can't be used, because one servlet may be mapped to oldschool *.do and another one to something like *.make.

User should see single cookie, but there are in fact more sessions in the same context for the same user - that's why I need to do the tricks with altering extended session ID to include a reference to selected (per request - depending on the target Servlet in the chain) ServletContextHelper...

I also have to do it for Tomcat and Undertow... Jetty is most flexible here anyway ;) (in Tomcat and Undertow I have to use thread locals...)

[janbartel]

Yikes! Well let me know if there is anything I can do api-wise to make your implementation work easier.

[grgrzybek]

I had a bit of issues when moving from Jetty 9/10 to 12, but all I felt was appreciation and admiration of what you went through trying to unify EE8-EE11 in Jetty 12 ;)

Having many years now of experience with Pax Web, I can honesty say that Jetty is the most flexible Servlet container implementation when trying to customize ;)
Tomcat is fine (however sometimes too generic with the concept of getPipeline().getFirst().invoke() at context/host/engine/wrapper level)
And Undertow callbacks are not super friendly in terms of extensions...

When I find something which could help here in Pax Web (and for all other embedders in general) I won't hesitate to ask.

For some time I had to copy org.eclipse.jetty.servlet.DefaultServlet from Jetty 9/10 to make some fields protected instead of private (mostly related to welcome files), but with Jetty 12 I don't have to do it anymore.

Just to give you a summary of current extensions of Jetty 12 in Pax Web:

• extends org.eclipse.jetty.ee10.servlet.FilterHolder - so I can get instances from OSGi services
• extends org.eclipse.jetty.ee10.servlet.FilterMapping - to keep OSGi model along the filter instance
• extends org.eclipse.jetty.ee10.servlet.ServletHolder - as with filter
• extends org.eclipse.jetty.ee10.servlet.ServletHandler
• extends org.eclipse.jetty.ee10.servlet.ServletContextHandler - big one - to deal with dynamic SCIs, OSGi-ranked listaners and bundle resources
• extends org.eclipse.jetty.ee10.servlet.ServletHandler - to calculate proper filter chain based on target servlet (to provide proper wrappers for servletcontext/config to get proper classloader according to Whiteboard specification
• extends org.eclipse.jetty.ee10.servlet.SessionHandler and extends org.eclipse.jetty.session.DefaultSessionIdManager - for the session ID hacks

So no more copy of any Jetty class.