You _should_ be able to do this with standard servlet configuration (a web.xml, or a equivalent code). Shiro will just use the available session from your container.
On Wed, Mar 29, 2017 at 12:56 AM, Harshdeep S Jawanda <[email protected]> wrote: > I have verified the following: > > - ServletContainerSessionManager integrates with the underlying way in > which GAE manages HTTP sessions, so should be the choice for people using > Shiro on GAE. > - Prepending _ahs to the value of JSESSIONID cookie gives the ID of > the _ah_SESSION entity in the GAE datastore (should this data be of use to > anybody else in the future). > - Setting session-timeout in web.xml works on GAE also (I'd had some > doubts regarding this). > - The JSESSIONID cookie resulting from the Shiro login process has no > expires value, therefore is valid for the current session only. > > Here is what I want to achieve: > > 1. I want to set an expires value on the JSESSIONID cookie so that it > isn't lost when the user closes the browser. > 1. I can achieve this by setting the maxAge of the cookie > explicitly in my login handler (after successful login). However this > still > leaves behind one issue... > 2. Just like the _expires value of the _ah_SESSION entity gets > updated every time a logged-in user uses the site (so that session remains > valid for X time from last activity), I want the expires value of the > JSESSIONID cookie to also get updated. > > How do I achieve this 2nd part? Shiro doesn't seem to handle this > automatically: is there some setting I have missed? Remember, I have to use > ServletContainerSessionManager and it doesn't have the > sessionIdCookie.maxAge property (plus I don't think the expires value gets > auto-updated every time anyway). > > Is my only viable option to create my own Filter? > > Or does an auto-refreshing cookie leave a security hole and is therefore > inadvisable? > > Regards, > Harshdeep S Jawanda > > On 29 March 2017 at 06:42, Harshdeep S Jawanda <[email protected]> > wrote: > >> But where does DefaultWebSessionManager keep the session? In RAM? Then >> how and when does it decide to end a session? >> >> Because of App Engine's peculiar nature (instances may be stopped and >> started at any time based on load, and consecutive calls from the same user >> may end up going to different instances), sessions have to be stored in >> their built-in Datastore. >> >> I had always thought that Shiro on GAE interacts with these sessions and >> uses them to correspond its own idea/implementation of sessions. You're >> saying that's not the case? >> >> >> Regards, >> Harshdeep S Jawanda >> >> On 29 March 2017 at 02:36, Brian Demers <[email protected]> wrote: >> >>> I cannot speak to anything specific to GAE, but the >>> DefaultWebSessionManager "owns" the creation of the sessionId. If you want >>> the container to control it, then you would use the >>> ServletContainerSessionManager: >>> >>> https://github.com/apache/shiro/blob/master/web/src/main/jav >>> a/org/apache/shiro/web/session/mgt/ServletContainerSessionManager.java >>> >>> On Mon, Mar 27, 2017 at 7:53 AM, Harshdeep S Jawanda < >>> [email protected]> wrote: >>> >>>> Hi all, >>>> >>>> I am trying to get a better understanding of how Shiro does session >>>> management on Google App Engine (a few things seem to be behaving >>>> counter-intuitively), so I'll start by asking some questions: >>>> >>>> 1. Does Shiro use the _ah_SESSION entities to manage session >>>> persistence on GAE? >>>> 2. If so, what is the relationship between the key (name/ID) of the >>>> _ah_SESSION entity and the value stored in the JSESSIONID cookie? >>>> 3. To put it differently, how does DefaultWebSessionManager know >>>> that if the JSESSIONID value is X, I have to lookup entity Y in the GAE >>>> datastore? >>>> >>>> I have set the session-timeout to 1440 (24 hours) in web.xml, but >>>> logins seem to expire before then (cookie life is set to 5 days): if I >>>> login now, do nothing after that, and refresh the page in, say, 13 hours, I >>>> am shown as logged out (depending entirely on Shiro for logins, not doing >>>> any other hanky-panky). >>>> >>>> It does seem like the value of the _expires field in the _ah_SESSION >>>> entities is being set to 24 hours from now. >>>> >>>> Regards, >>>> Harshdeep S Jawanda >>>> >>> >>> >> >
