Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 319137

Summary: JDBCSessionManager doesn't share sessions across webapps
Product: [RT] Jetty Reporter: Bob Obringer <bobringer>
Component: serverAssignee: Greg Wilkins <gregw>
Status: CLOSED WONTFIX QA Contact:
Severity: enhancement    
Priority: P3 CC: bobringer, jetty-inbox, mgorovoy
Version: unspecified   
Target Milestone: 7.1.x   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Patch to enable SharedSessionPath context-param
none
FIXED Patch to enable SharedSessionPath none

Description Bob Obringer CLA 2010-07-07 10:28:20 EDT 
Build Identifier: jetty-hightide-7.1.5.v20100705

A recent fix allows you to set a session cookie at a global path for a session instead of using the context path:  https://bugs.eclipse.org/bugs/show_bug.cgi?id=294212  This allows you to use "/" for your session cookies even though your context paths may be /webapp1 and /webapp2.  To enable this, place the following in web.xml or webdefault.xml:

	<context-param>
		<param-name>org.eclipse.jetty.servlet.SessionPath</param-name>
		<param-value>/</param-value>
	</context-param>

This works for the cookie, but still does not allow you to share the session across webapps.

JdbcSessionManager allows you to persist your session in a back end database, and out of the box this works well to enable a session to live between server reboots.  Currently, it does not allow you to share the session across webapps.  JdbcSessionManager stores your session in MySQL using the context path as part of it's key regardless of whether or not you use a session path, so even though your cookies are all at "/" the context that set the cookie is the only one with access to the session.

I have made the following changes to allow JdbcSessionManager to share sessions across contexts:

org.eclipse.jetty.server.handler.ContextHandler.Context:
* Add getSessionPath():
        public String getSessionPath() {
        	return getInitParameter(SessionManager.__SessionPathProperty);
        }


org.eclipse.jetty.server.session.JDBCSessionManager:
* Add getContextSessionPath():
    private String getContextSessionPath() {
    	return (_context.getSessionPath() == null) ? _context.getContextPath() : _context.getSessionPath();
    }

* Replace all instances of _context.getContextPath() with getContextSessionPath()

After recompiling with these changes, I was able to sign in to /webapp1 and have my session available to /webapp2.  Without the ability to share sessions across contexts, JDBCSessionManager is very limited.  These minor changes greatly improve the functionality of JDBCSessionManager.

Reproducible: Always
Comment 1 Greg Wilkins CLA 2010-07-07 19:29:53 EDT 
The non sharing of sessions between webapps is actually by design.   The spec allows for the sharing of a session ID, but each session should have it's own unique session map.  The reason for this is that the objects placed into the session are going to be for classes loaded by the context classloader, and thus may be unusable by another context.

However, I can see that with the JDBC session manager, objects are serialized and reloaded... so that avoids the classloading problem.  So we will see if we can make this behaviour optional.
Comment 2 Bob Obringer CLA 2010-07-08 17:50:24 EDT 
I understand the issue.  In my case though, using JDBCSessionManager would be an incredibly simple way to handle single sign on in our environment.

We are building a fairly large intranet (from the ground up... migrating from domino).  Our intranet may contain over 50 webapps.  It is important that we keep these as separate apps in our environment.  JDBCSessionManager is a really elegant solution for us to be able to maintain sessions across server instances and reboots.  Using it for single sign on as well would be outstanding.

In my case, the change I made is to enable this ONLY if the SessionPath is explicitly set on a webapp.  If the SessionPath is set, I use it to build the jdbc session instead context path.  This way, if two contexts use a session cookie at a single path, I assume that I also want to share the session across those contexts.  I assume there may be situations where this wouldn't be the case and so an optional setting.

We're moving pretty quickly on this stuff, so I'll be working up a patch tonight.
Comment 3 Bob Obringer CLA 2010-07-08 22:35:01 EDT 
Created attachment 173834 [details]
Patch to enable SharedSessionPath context-param

What I've done for now is added the ability to include the following context-param (in my case to webdefault.xml):

<context-param>
	<param-name>org.eclipse.jetty.servlet.SharedSessionPath</param-name>
	<param-value>/shared/session/path</param-value>
</context-param>

This allows you to have multiple shared session paths, so some apps can use their own shared session while other apps use the default shared session.

The attached patch implements these changes.


For now... this seems to be working well for me.
Comment 4 Bob Obringer CLA 2010-07-08 22:37:52 EDT 
(In reply to comment #3)
> Created an attachment (id=173834) [details]
> Patch to enable SharedSessionPath context-param
> 
> What I've done for now is added the ability to include the following
> context-param (in my case to webdefault.xml):
> 
> <context-param>
>     <param-name>org.eclipse.jetty.servlet.SharedSessionPath</param-name>
>     <param-value>/shared/session/path</param-value>
> </context-param>
> 
> This allows you to have multiple shared session paths, so some apps can use
> their own shared session while other apps use the default shared session.
> 
> The attached patch implements these changes.
> 
> 
> For now... this seems to be working well for me.

Obviously... without the horrid System.out.println() lines.  Didn't have the logger being used handy and was just looking for some quick info.</dumb>
Comment 5 Bob Obringer CLA 2010-07-08 22:40:46 EDT 
Created attachment 173835 [details]
FIXED Patch to enable SharedSessionPath

Patch to enable SharedSessionPath context-param
Comment 6 Greg Wilkins CLA 2010-07-09 00:22:26 EDT 
thanks,

I'll look at this shortly and will have something for this in the next release.
Comment 7 Bob Obringer CLA 2010-07-09 11:18:55 EDT 
First... The decision to move to Jetty from Domino has been validated as the right move... for no other reason then the responsiveness I've seen out of you guys.  Not just here... but on various blogs and other random places I've come across your posts.  This is very encouraging for our future.

That being said, I wonder if the solution I've proposed isn't specialized enough that *I* should look for an alternative solution, using JDBCSessionManager to share Session IDs and then use those ID's to roll my own session information.  This would match the original intention of JDBCSessionManager.

In my case, I DO need to retrieve updated session information when I change session information in one context... if the session in a second context is already in memory, it doesn't pick up the changes.  This defeats the purpose (as you mentioned in your first response).

For now... I'm going to back out my changes, and roll my own method to retrieve updated session information.  I have a real world situation that may provide some insight as to future enhancements you might want to make, so I will be more than happy to provide any assistance.  Eventually... the work I'm doing will be well documented in a yet to be developed blog.
Comment 8 Greg Wilkins CLA 2011-01-10 11:00:13 EST 
Bob

ARGH!  You praise us on responsiveness, then I fall off this issue for 6 months!
Really sorry about that!!!!

But yes - I think what you are doing is special enough that it really should have it's own session manager... perhaps derived off the jetty session managers.

I assume that because you've not commented for a while, your approach has been working fine.  So I will close this issue.

If there is anything you need in the jetty session managers to help your customisation, then please reopen and we can discuss.
Comment 9 Bob Obringer CLA 2011-01-13 19:11:35 EST 
(In reply to comment #8)

Greg,

Some color.  I'm building an intranet that has a top level webapp (authentication, homepage and other global things).  Beneath that webapp, we have individual webapps for each of our business groups.  I'm looking for a way to maintain session information across all of these apps.

So, I've got my own custom sessions stored in a table.  JDBCSessionIdManager provides me with a global session id that I can use to access my custom sessions.  Pretty simple and it's working perfectly.  At this time, I'm using JDBCSessionIdManager for (what I think it) it's intended purpose... and I have a very simple solution to associate those sessions with my own custom sessions.

I'd imagine this is a much better solution than my original proposal.



> Bob
> 
> ARGH!  You praise us on responsiveness, then I fall off this issue for 6
> months!
> Really sorry about that!!!!
> 
> But yes - I think what you are doing is special enough that it really should
> have it's own session manager... perhaps derived off the jetty session
> managers.
> 
> I assume that because you've not commented for a while, your approach has been
> working fine.  So I will close this issue.
> 
> If there is anything you need in the jetty session managers to help your
> customisation, then please reopen and we can discuss.