I suspect that you are actually getting the same security manager. What I suspect is actually happening is that since the Shiro module binds a SessionManager as well, your SecurityManager is getting injected with the Guice-created SessionManager. Notice that the property you're setting and checking isn't actually on the SecurityManager, but is rather on the SessionManager. Arguably it shouldn't do this since you bound to an instance. So I'm going to need to look further into this to see if a fix is warranted or possible.
That being said, I highly recommend that you don't use the IniSecurityManagerFactory with the Guice integration. You're essentially giving up the Guice DI in favor of the Ini Factory's. Really, once you are using Guice (or Spring) for DI, I wouldn't use the Ini for anything except user/permission definitions, and even that is probably not the best choice for applications of any significant complexity. Instead, you have two options. You could override bindSessionManager and instantiate a SessionManager and set those values on it, or you can use the Shiro-Guice property binding, discussed here: http://shiro.apache.org/guice.html#Guice-Properties If you need more details on that let me know, I can probably get you some example code in the morning. -Jared On Wed 02 Nov 2011 05:09:05 PM CDT, chengas123 wrote: > Les, Manoj, thank you for the suggestions. I think I have found my problem > and am wondering if you might know what's going wrong. The problem is that > my settings are being ignored because the SecurityManager being used is not > the one I'm creating in my module. > > Here's where I provide my SecurityManager: > > @Override > protected void bindSecurityManager(AnnotatedBindingBuilder<? super > SecurityManager> bind) { > Ini ini = new Ini(); > ini.setSectionProperty("main", > "securityManager.sessionManager.globalSessionTimeout", "1000"); > ini.setSectionProperty("main", > "securityManager.sessionManager.sessionValidationInterval", "3000"); > > SecurityManager securityManager = new > IniSecurityManagerFactory(ini).getInstance(); > > // Make sure the session timeout is actually being set to 1000 > try { > System.out.println(PropertyUtils.getNestedProperty(securityManager, > "sessionManager.globalSessionTimeout")); > } catch (IllegalAccessException e) { > throw new RuntimeException(e); > } catch (InvocationTargetException e) { > throw new RuntimeException(e); > } catch (NoSuchMethodException e) { > throw new RuntimeException(e); > } > > bind.toInstance(securityManager); > } > > Then if I try to get an instance of it, I am given a different instance > instead: > > public static void main(String[] args) throws Exception { > Injector injector = Guice.createInjector( > Stage.PRODUCTION, > new BensShiroModule()); > > SecurityManager securityManager = > injector.getInstance(SecurityManager.class); > > // Why is the session timeout 1800000 here? > try { > System.out.println(PropertyUtils.getNestedProperty(securityManager, > "sessionManager.globalSessionTimeout")); > } catch (IllegalAccessException e) { > throw new RuntimeException(e); > } catch (InvocationTargetException e) { > throw new RuntimeException(e); > } catch (NoSuchMethodException e) { > throw new RuntimeException(e); > } > } > > > Thanks again for the help, > Ben > > > On Tue, Nov 1, 2011 at 6:51 PM, Les Hazlewood-2 [via Shiro User] < > [email protected]> wrote: > >> Hi Ben, >> >>> securityManager.subjectDAO.sessionStorageEvaluator.sessionStorageEnabled >> = >>> false >> >> This prevents Shiro from using a Subject's Session for Shiro's own >> needs. It does not prevent you, the application developer (or >> something under your control, like a JSP page or other web component), >> from using Sessions. >> >> More info here: >> >> >> http://shiro.apache.org/session-management.html#SessionManagement-DisablingSubjectStateSessionStorage >> >> (note the yellow warning box). >> >> Odds are high that another part of your app (or a JSP page) is trying >> to use or create a session (e.g. via request.getSession()). If using >> JSP, ensure you have the following directive at the top of the page: >> >> <%@ page session="false" %> >> >> Additionally for web apps, you may wish to disable sessions entirely >> under a particular URL or URLs: >> >> >> http://shiro.apache.org/session-management.html#SessionManagement-WebApplications >> >> Another approach is to create a SessionManager implementation that >> always throws an exception when 'start' is called and configure that >> on the SecurityManager, e.g. >> >> securityManager.sessionManager = $noSessionManager >> >> HTH! >> >> Cheers, >> >> -- >> Les Hazlewood >> CTO, Katasoft | http://www.katasoft.com | 888.391.5282 >> twitter: @lhazlewood | http://twitter.com/lhazlewood >> katasoft blog: http://www.katasoft.com/blogs/lhazlewood >> personal blog: http://leshazlewood.com >> >> >>> >>> We're getting an ExpiredSessionException after 30 minutes. This seems >> weird >>> to me since we want sessions turned off to run in sessionless mode. >>> >>> We're logging the user in with every request since we're sessionless. >> Is >>> this the wrong thing to be doing? >>> SecurityUtils.getSubject(); >>> UsernamePasswordToken token = new UsernamePasswordToken(user, pass); >>> try { >>> currentUser.login(token); >>> } ... >>> >>> The stacktrace we're getting is below. We're using >>> org.apache.shiro:shiro-core:1.2.0-SNAPSHOT from the snapshot Maven >>> repository. >>> >>> org.apache.shiro.session.ExpiredSessionException: Session with id >>> [2840cc08-d5d0-4e84-80c0-3249242b8a3d] has expired. Last access time: >>> 11/1/11 12:01 PM. Current time: 11/1/11 12:53 PM. Session timeout is set >> to >>> 1800 seconds (30 minutes) >>> >>> >> org.apache.shiro.session.mgt.SimpleSession.validate(SimpleSession.java:292) >>> >>> >> org.apache.shiro.session.mgt.AbstractValidatingSessionManager.doValidate(AbstractValidatingSessionManager.java:180) >> >>> >>> >> org.apache.shiro.session.mgt.AbstractValidatingSessionManager.validate(AbstractValidatingSessionManager.java:143) >> >>> >>> >> org.apache.shiro.session.mgt.AbstractValidatingSessionManager.doGetSession(AbstractValidatingSessionManager.java:120) >> >>> >>> >> org.apache.shiro.session.mgt.AbstractNativeSessionManager.lookupSession(AbstractNativeSessionManager.java:105) >> >>> >>> >> org.apache.shiro.session.mgt.AbstractNativeSessionManager.lookupRequiredSession(AbstractNativeSessionManager.java:109) >> >>> >>> >> org.apache.shiro.session.mgt.AbstractNativeSessionManager.removeAttribute(AbstractNativeSessionManager.java:220) >> >>> >>> >> org.apache.shiro.session.mgt.DelegatingSession.removeAttribute(DelegatingSession.java:159) >> >>> >>> >> org.apache.shiro.session.ProxiedSession.removeAttribute(ProxiedSession.java:135) >> >>> >>> >> org.apache.shiro.session.ProxiedSession.removeAttribute(ProxiedSession.java:135) >> >>> >>> >> org.apache.shiro.subject.support.DelegatingSubject.clearRunAsIdentities(DelegatingSubject.java:456) >> >>> >>> >> org.apache.shiro.subject.support.DelegatingSubject.login(DelegatingSubject.java:258) >> >>> >>> Thanks for the help, >>> Ben >>> >>> -- >>> View this message in context: >> http://shiro-user.582556.n2.nabble.com/Session-expiration-when-using-stateless-application-tp6953312p6953312.html >>> Sent from the Shiro User mailing list archive at Nabble.com. >> >> >> ------------------------------ >> If you reply to this email, your message will be added to the discussion >> below: >> >> http://shiro-user.582556.n2.nabble.com/Session-expiration-when-using-stateless-application-tp6953312p6953876.html >> To unsubscribe from Session expiration when using stateless application, >> click >> here<http://shiro-user.582556.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=6953312&code=YmVuamFtaW4uai5tY2Nhbm5AZ21haWwuY29tfDY5NTMzMTJ8NjMwOTMwNjQ1>. >> >> > > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/Session-expiration-when-using-stateless-application-tp6953312p6957151.html > Sent from the Shiro User mailing list archive at Nabble.com.
