You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by chengas123 <be...@gmail.com> on 2011/11/01 22:25:39 UTC
Session expiration when using stateless application
Hi,
We're just getting started with Shiro and want to use it in sessionless
mode. In our shiro.ini we set:
securityManager.subjectDAO.sessionStorageEvaluator.sessionStorageEnabled =
false
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.
Re: Session expiration when using stateless application
Posted by Manoj Khangaonkar <kh...@gmail.com>.
Hi,
Are you logging out after each request ?
If not I would expect the session to lie around and eventually expire,
which might be the message you are seeing.
On looking around I notice that AbstractValidatingSessionManager has a
public void setSessionValidationSchedulerEnabled(boolean
sessionValidationSchedulerEnabled)
method. If you want to disable session validation, try setting this
property to false
Manoj
On Tue, Nov 1, 2011 at 2:25 PM, chengas123 <be...@gmail.com> wrote:
> Hi,
> We're just getting started with Shiro and want to use it in sessionless
> mode. In our shiro.ini we set:
> securityManager.subjectDAO.sessionStorageEvaluator.sessionStorageEnabled =
> false
>
> 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.
>
--
http://khangaonkar.blogspot.com/
Re: Session expiration when using stateless application
Posted by chengas123 <be...@gmail.com>.
Hi Jared, thanks for the help. Still having a bit of difficulty though.
Even when I set the constant using the way you mentioned [
bindConstant().annotatedWith(Names.named("shiro.globalSessionTimeout")).to(1000L)],
I still don't see it being set in the injected SecurityManager. If I print
out the global session timeout value for the injected SecurityManager I
get 1800000 no matter what.
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);
}
}
On Wed, Nov 2, 2011 at 8:20 PM, Jared Bunting-2 [via Shiro User] <
ml-node+s582556n6957796h30@n2.nabble.com> wrote:
> On Wed 02 Nov 2011 08:33:52 PM CDT, Jared Bunting wrote:
>
> > 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] <
> >> [hidden email] <http://user/SendEmail.jtp?type=node&node=6957796&i=0>>
> 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<
> >>>
> >>>
> >>
> >>
> >> --
> >> 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.
> >
> >
> Found some time tonight.
>
> Example:
>
> Remove your bindSecurityManager method and augment your configureShiro
> method as follows.
>
> public class BensShiroModule extends ShiroModule {
> public void configureShiro() {
> // realm configuration here
>
> bindConstant().annotatedWith(Names.named("shiro.globalSessionTimeout")).to(1000L);
>
>
> bindConstant().annotatedWith(Names.named("shiro.sessionValidationInterval")).to(3000L);
>
> }
> }
>
>
>
> ------------------------------
> 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-tp6953312p6957796.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-tp6953312p6958257.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Session expiration when using stateless application
Posted by Jared Bunting <ja...@peachjean.com>.
On Wed 02 Nov 2011 08:33:52 PM CDT, Jared Bunting wrote:
> 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] <
>> ml-node+s582556n6953876h10@n2.nabble.com> 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.
>
>
Found some time tonight.
Example:
Remove your bindSecurityManager method and augment your configureShiro
method as follows.
public class BensShiroModule extends ShiroModule {
public void configureShiro() {
// realm configuration here
bindConstant().annotatedWith(Names.named("shiro.globalSessionTimeout")).to(1000L);
bindConstant().annotatedWith(Names.named("shiro.sessionValidationInterval")).to(3000L);
}
}
Re: Session expiration when using stateless application
Posted by Jared Bunting <ja...@peachjean.com>.
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] <
> ml-node+s582556n6953876h10@n2.nabble.com> 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.
Re: Session expiration when using stateless application
Posted by chengas123 <be...@gmail.com>.
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] <
ml-node+s582556n6953876h10@n2.nabble.com> 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.
Re: Session expiration when using stateless application
Posted by Les Hazlewood <lh...@apache.org>.
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.