Yes, Shiro does use JSESSIONID in native mode. Shiro fully implements the servlet specification with respect to sessions - the spec uses JSESSIONID as the example that can be used by the implementation.
When using the ShiroFilter, as long as it is the first in the chain (or high enough in the chain such that nothing before it uses the session), the servlet container will never be consulted for a session. Shiro intercepts all HttpServletRequest calls to acquire the session, ensuring native sessions are used. You want this to occur - if sessions are being dropped and you're seeing sessions disappear - either Shiro's or the Servlet Container's - then it means they're conflicting with each other or something is interfering with the implementation. You don't want to maintain 2 session objects for the same user - data will be inconsistent. You could change the session id's cookie name to get around this, but I don't recommend it - you're only side-stepping the root problem and you're likely to have adverse effects (inconsistent data, lower performance due to updating 2 sessions always, etc). Does Grails modify the JSESSIONID cookie? Any idea why this would happen? - Les On Tue, Dec 15, 2009 at 11:43 AM, Peter Ledbrook <[email protected]> wrote: > Hi, > > A user is having problems with a Grails application + Shiro plugin: > > http://jira.codehaus.org/browse/GRAILSPLUGINS-1742 > > Basically, whenever the flash is modified, his session is dropped. > I've debugged through the code and it seems that even in native mode, > Shiro is using the JSESSIONID cookie. I don't know why it's happening, > but the JSESSIONID cookie changes to the usual hash after the flash is > modified. Perhaps a bug in Grails, but isn't it a bit dangerous to > hijack the JSESSIONID cookie for our own purposes? > > Cheers, > > Peter >
