Yes, this is if you are using Shiro's native session manager configuration (usually used when performing container-agnostic clustering).
Cheers, Les On Fri, Dec 14, 2012 at 3:04 AM, Paulo Pires <[email protected]> wrote: > OK, I can see this is only intended for Shiro native session management. > > > > On 14/12/12 10:56, Paulo Pires wrote: > > I'm trying this: > > ## session timeout > sessionManager = org.apache.shiro.web.session.mgt.DefaultWebSessionManager > securityManager.sessionManager = $sessionManager > securityManager.sessionManager.globalSessionTimeout = 86400000 > > > Let me know your thoughts, if any, please. > > Tks, > PP > > On 14/12/12 10:42, Paulo Pires wrote: > > securityManager.sessionManager.globalSessionTimeout > > is this it? > > On 14/12/12 10:39, Paulo Pires wrote: > > Hi list, > > I've implemented a REST application that uses Shiro + JDBC Realm for > authentication. > This application has a few clients (applications + a web-site) that > perform authentication, store the response cookie and use the same cookie > when asking for REST resources. > > As my REST environment is a Glassfish cluster, I have my sessions being > replicated and everything works great for a time - I can't precise how > much, though. After some time, the cookie is accepted by Glassfish but > Shiro complains: > > org.apache.shiro.authz.UnauthenticatedException: The current Subject is > not authenticated. Access denied. > Caused by: org.apache.shiro.authz.AuthorizationException: Not authorized > to invoke method: public javax.ws.rs.core.Response com.... > > org.apache.shiro.authz.aop.AuthorizingAnnotationMethodInterceptor.assertAuthorized(AuthorizingAnnotationMethodInterceptor.java:90) > > Sessions live for 24 hours. Any idea on what's happening? > > Cheers, > > -- > Paulo Pires > > > -- > Paulo Pires > > > -- > Paulo Pires > > > -- > Paulo Pires > >
