Jerry,
On 12/1/15 3:11 PM, Jerry Malcolm wrote:
> On 12/1/2015 1:28 PM, Christopher Schultz wrote:
>> Jerry,
>>
>> On 12/1/15 12:30 PM, Jerry Malcolm wrote:
>>> I'm looking for a way to detect that the current session has expired (or
>>> logged out via another tab on the browser). I know I could just issue
>>> dummy requests to the server and see if a login page comes back. But
>>> issuing requests automatically resets the session timer. I need a benign
>>> way to query that doesn't keep the session alive forever.
>>>
>>> I'm sure this problem has been solved before. But basically, I want to
>>> know that the session is no longer valid and force the user back to the
>>> login page. I know one possibility is to set the Tomcat timer to 30 min
>>> expiration, and then keep a '29 minute' timer running in the browser.
>>> But my clients can change the tomcat session timer length.
>> When you generate your HTML page, toss the
>> HttpSession.getMaxInactiveInterval into the page somewhere, then wait
>> that number of minutes. Don't hard-code 29 minutes (though 31 would have
>> been a better time to wait if you didn't want to automatically-extend
>> the session).
>>
>>> And also this doesn't account for a logoff using the same session on
>>> a different browser tab. I'd really like a pro-active query method
>>> if anything like that exists.
>> Try something like this:
>>
>> - Set -Dorg.apache.catalina.core. StandardHostValve.ACCESS_SESSION=false
>> (false is the default if org.apache.catalina.STRICT_SERVLET_COMPLIANCE
>> is not set to "true")
>
> Does this go in service.bat? Separate line?
I would put it into CATALINA_HOME/bin/setenv.bat rather than anywhere
else. That is, if you actually do launch Tomcat from the command-line.
Most Windows users run Tomcat from the service snap-in, which means
you'll have to re-configure that using tomcatNw.exe (where N is your
Tomcat version -- you didn't say what you were running) and editing the
system properties that will be set on JVM launch.
>> - Write a quick page like this:
>>
>> session-check.jsp:
>> <?jsp session="false" contentType="application/json" ?>
>> { "valid" : <%= request.isRequestedSessionIdValid() %> }
>>
>> Then you can request this page to see the value of "valid".
>>
>> I wasn't able to tell if the isRequestedSessionIdValid method is
>> supposed to "touch" the session's last-update-timestamp. I read some
>> code in Tomcat and didn't find a "touch" but that doesn't mean it
>> couldn't change. I didn't see anything in the spec that specifically
>> said that method doesn't "touch" the session.
>
> This makes sense as long as it truly does not keep the session alive.
Right. I can't prove it will work, but it's quite easy to try it. You
could even temporarily set your session timeout to 5 minutes to make the
test go faster.
> Just to be sure I understand things, if I first access an unprotected
> file requiring no login, I'll have a valid session.
That's not necessarily true.
> But I'll still get the login page if later I access a protected file
> in that same session, correct?
Session doesn't always mean login, but the servlet spec indicates that,
once authenticated using FORM authentication (specifically), that the
termination of the HttpSession is synonymous with being logged-out. If
you then try to access a protected page, you'll get the login page.
But the converse is not true: merely having an HttpSession available
does not mean that you have been authenticated.
> Not a big deal. I'll just have to only use this on pages that
> assure a login has occurred. Also, I assume I should put the
> session-check.jsp in an unprotected folder, otherwise I'll get a login
> challenge before I even can get to the session-check, right?
Note that the JSP I provided won't tell you if the user is logged-in; it
will only tell you if the session is valid.
If you want to know both, you can do that:
session-check.jsp:
<?jsp session="false" contentType="application/json" ?>
{
"valid" : <%= request.isRequestedSessionIdValid() %>,
"authenticated": <%= request.isRequestedSessionIdValid() ? null !=
request.getUserPrincipal() : "false" %>
}
(Note that I predicate the request.getUserPrincipal call because I'm
fairly sure that will trigger a session touch. The idea is to avoid
prolonging an /authenticated/ session, but you don't care how long an
unauthenticated session persists, right?
There are other, uglier and less-portable ways to do this, but if you
can stick within the spec-defined APIs you'll be better off.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
