Is JSESSIONID generation overtaken by Shiro with native sessions?

[martinso <ma...@mjukkultur.se>]

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.

Re: Is JSESSIONID generation overtaken by Shiro with native sessions?

[martinso <ma...@mjukkultur.se>]

Lez,

Thanks again. Your quick responses to questions here are very much
appreciated! I'll try what you suggest, and when everything works as
expected I'll be happy to add an issue in Jira.

/Martin

--
View this message in context: http://shiro-user.582556.n2.nabble.com/Is-JSESSIONID-generation-overtaken-by-Shiro-with-native-sessions-tp6246787p6247256.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Is JSESSIONID generation overtaken by Shiro with native sessions?

[Les Hazlewood <lh...@apache.org>]

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 <ma...@mjukkultur.se> 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.