I'm having a bit of trouble with Session timeouts in my Tomcat served web application. From reading over Tomcat's documentation, sessions expire after a time which can be configured in the web.xml file.
<session-config>
<session-timeout>30</session-timeout>
</session-config>
Quesion) Does this mean 30 minutes from when the session was created for the user? Or 30 minutes from when the session was last accessed?
If it is, as I originally thought, 30 minutes from when the session was last accessed, I don't seem to be seeing this behavior. My sessions seem to be lost as I'm using the site. Are there any other ways to configure session behavior besides this one setting? Is there something I'm missing?
Apache Tomcat/6.0.20
A session is started for the web browser when it connects to your application. Tomcat closes the session on the server when the maximum period of inactivity has passed (30 minutes).
This timeout is reset whenever there is activity on the web browser, such as refreshing the current page or navigating through other pages under the application control. Merely keeping a browser window open does not keep the session open because it does not generate any activity on the browser.
You can set it in the web.xml file as you described.
You can also set it for the session object by calling setMaxInactiveInterval(int interval)
This specifies the time, in seconds, between client requests before the servlet container will invalidate this session.
You have to make sure, that the cookies are enabled for your browser. Otherwise you create a new Session with each request. You should call the HttpServletResponse.encodeURL(String url) for each URL in your application. From the api doc:
"Encodes the specified URL by including the session ID in it, or, if encoding is not needed, returns the URL unchanged. The implementation of this method includes the logic to determine whether the session ID needs to be encoded in the URL. For example, if the browser supports cookies, or session tracking is turned off, URL encoding is unnecessary.
For robust session tracking, all URLs emitted by a servlet should be run through this method. Otherwise, URL rewriting cannot be used with browsers which do not support cookies."
Related
We are using Vaadin 14 on a Tomcat9.
A session is immediately created in Tomcat as soon as the login page of our app is called up. If a lot of sessions have been created here (e.g. penetration test), the Tomcat takes a very long time to delete them. The CPU load also rises to 100%.
Is it possible to prevent the automatic creation of a session and only create one after the login?
We have reduced the session timeout in Tomcat so that there are not so many open sessions.
You can not use Vaadin (for your Login) and no sessions. Vaadin stores the
state of the UI in the session and there is no way around it:
A user session begins when a user first makes a request to a Vaadin servlet
by opening the URL of a particular UI. All server requests belonging to
a particular UI class are processed by the VaadinServlet class. When a new
client connects, it creates a new user session, represented by an instance of
VaadinSession. Sessions are tracked using cookies stored in the browser.
https://vaadin.com/docs/latest/advanced/application-lifecycle/#application.lifecycle.session
So you have to prevent this and not send your users directly into the
Vaadin application (first). In your case you could provide a login form
or some SSO gatekeeper to "protect" your resources.
I have a Spring MVC App and I have an issue with invalidated sessions.
The app performs AJAX requests that are all authenticated/tied to a session (hold a JSESSIONID)
So here's what happens. Let's say I'm in the app authenticated with a session. If I go into Tomcat and invalidate that session, then the next time an HTTP request gets made, Spring forwards me to the login page. Once I login again, Spring authenticates me fine, but then a number of my AJAX requests get HTTP 403 errors, continuously.
If I go into the HTTP Headers of the requests that get the 403s, I notice they have 2 JSESSIONIDs, one of the authenticated session, the other one of a session that holds only this attribute:
SPRING_SECURITY_SAVED_REQUEST DefaultSavedRequest[<OLD URL>]
So these sessions are not authenticated sessions so they are causing Spring to return a 403.
The issue is that this persists until I kill the browser (on some mobile devices that doesn't even work, and I have to go into settings to clear the browser cache).
Any suggestions?
this is a big problem because it's happening when Sessions invalidate themselves because of TTL, and we're stuck with users who get booted out, log back in and still get 403s, forever, until they clear the cache.
One thing to note is that Spring Security invalidates the existing session when you login and creates a new one, copying the contents of the old one across. This is intended to create a new session identifier to avoid session fixation attacks. You can try disabling this feature to see if it is related to your problem. It sounds like these are the two sessions you are talking about.
However if there are two JSESSIONID headers in the request then it sounds like a problem on the client side. You should work out why your client is sending two values. Also, it sounds like there may be an issue with Tomcat on the server side if you are still able to read the contents of the previously invalidated session.
Also check that Tomcat isn't sending two JSESSIONID values in the login response. There was an issue ages ago where it was doing just that, but it's unlikely you are running such an old version of Tomcat.
We are currently running into a problem with session time outs on one of our Spring web applications. The session never times out because we have a continuous ajax request polling the server. Is there a way to tell spring to ignore this request and not update the session so that time out works as expected?
You could run a timer, equal to your session timeout, along side the continuous ajax request that would log the user out if the page never refreshes. Another idea would be to host the URL that you are hitting in a separate web application on the same domain. I'm not sure if Spring has something built in for what you are doing.
I thought about this some more. You could implement your own session registry that ignores the Ajax URLs. Basically you wouldn't set the last accessed time for a user in the session registry if the URL matched one that you defined in your ignore list or filter defined in the Spring Security filter chain.
See SessionRegistry
In my web application(jsp/servlet) there is a web page which create Ajax request periodically to grab the latest data from the server.This page is the main page which is always open once user log in to the system while other pages open in new browser windows(due to user events).
I have to invalidate the user session which idle for more than 30 minutes. For that I use Tomcat session timeout feature. But the thing is most of the time users session which are idle for 30 min are not invalidated.
But some time user sessions are invalidated by Tomcat after 30 min. I think this is because the main page send Ajax request periodically without idling the session.
I want to know that is Tomcat can't identified the auto generated request from user event and invalidate session properly.Please give an ideas on this,it will be very helpful for me.
Dinesh
I don't think you have a choice here - if Tomcat identifies and ignores the AJAX request, you'll lose the functionality it provides for you
How do websites generally log users out and send them to the log in screen automatically when a user's session expires? Is this done through ajax or running async handlers? Can you give me a bit of an explanation.
Banks and such use a client-side timeout via javascript, or something similar. Really, though, the server handles the actual session, so if you disabled the client-side logic it would act as if you were attempting to make transactions while logged out.
Use a cookie as well as a session.
Cookie must be set when a session is
started.
If the cookie is present but the
session is gone, redirect to the
login screen.
If there is no session and no cookie
do nothing
(pardon me if you can't do that because I never used ASP and basing my answer on my PHP knowledge)
Typically, you set an expiration timestamp on your session ID cookie. When the cookie fails to be sent, the client is logged off (no given session ID).
This method is often combined with JavaScript and another timestamp token. When the timers start running down, a notification is sent that allows the user to "refresh" their session... essentially, making a request before the session timestamp expires.
The "refresh" request could be anything, even something as simple as an image load.
If you are using Tomcat you can use its built in <security-constraint> mechanism within your web.xml definition. All of the timing, login screen, and page redirects are handled by Tomcat with little effort on your part other than definitions.
Oh, IIS... nevermind.