Yes, Shiro sets the JSESSIONID cookie when in native session mode. Shiro must replicate all of the Session-related behavior of a standard Servlet Container to guarantee full session support. Native sessions completely bypass the Servlet Container session mechanism. It has to do this for the following reasons:
- Without this behavior, you'd have 2 different sessions started (one by the servlet container, one by Shiro's native session manager). This would be bad for resource management. - Likely either the servlet container's or Shiro's JSESSIONID cookie would overwrite the other, orphaning the other session. To support your request, I'd do the following: 1. Subclass the DefaultWebSessionManager's [1] storeSessionId method to append a value at the end of the generated session ID before cookie.setValue is called. 2. Open a Jira to ask for this feature to be added to Shiro so you can remove your custom subclass. After it is implemented, you'll be able to configure this directly, e.g. in shiro.ini: securityManager.sessionManager.workerName = node1 HTH! [1] https://svn.apache.org/repos/asf/shiro/trunk/web/src/main/java/org/apache/shiro/web/session/mgt/DefaultWebSessionManager.java Cheers, -- Les Hazlewood Founder, Katasoft, Inc. Application Security Products & Professional Apache Shiro Support and Training: http://www.katasoft.com On Wed, Apr 6, 2011 at 9:52 AM, martinso <[email protected]> wrote: > HI, > > We used to have the web security manager using http sessions but have now > switched to using native sessions to be able to use the seucurity manager > also in non-web contexts in the JVM. We are running an embedded Jetty server > that we configure for Apache loadbalancing with sticky sessions like this: > > import org.mortbay.jetty.Server; > import org.mortbay.jetty.servlet.HashSessionIdManager; > > Server server = new Server(); > HashSessionIdManager sessionIdManager = new HashSessionIdManager(); > sessionIdManager.setWorkerName("node1"); > server.setSessionIdManager(sessionIdManager); > > We have the IniShiroFilter configured in web.xml. > > With Shiro configured for http sessions, web requests will have JSESSIONID's > ending with ".node1" as expected when hitting the server directly, but now > with native sessions we don't have this anymore, the JSESSION looks like I > is not even generated by Jetty (which usually has shorter ids than what we > see). It feels as if Shiro takes over and supplies a JSESSIONID of its own. > Does anyone understand what is going on here? > > /Martin > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/Is-JSESSIONID-generation-overtaken-by-Shiro-with-native-sessions-tp6246787p6246787.html > Sent from the Shiro User mailing list archive at Nabble.com.
