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
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 am trying to implement CSRF protection in an existing application. We have Spring MVC on backend and a mix of HTML, CSS and Apache Velocity Templates on frontend.
I have tried configuring the Spring CSRF functionality as shown here - https://docs.spring.io/spring-security/site/docs/current/reference/html/csrf.html. After reading through this Spring documentation, I get a feel that after configuration, Spring Security would automatically send tokens with all requests but that is not happening in my case - perhaps something is wrong with my configuration.
As an alternative, I am creating an instance of Spring Security's CsrfTokenRepository and calling generateToken and loadToken methods on it in my front controller which intercepts all HTTP requests coming to the server. This way, I am able to deliver a new token for every HTTP request and then send it back on the next one.
The mechanism fails though if I click different links within my page too frequently - by the time a page is rendered and the new token is set in hidden fields, the browser has already sent a request to another page with an old token. It also fails when I open more than one tab since the token received by the latest opened tab wins over tokens from tabs opened before it.
To overcome this issue, I changed the tokens to be generated only per session. However, now I run the risk of tokens being exposed - via get requests or referrer fields for example. Is there a way to improve the performance of per request tokens? or make the approach more secure with per session tokens?
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.
I am working for a client that has it's own session management system in case of idle timeouts. What happens is the following :
User stays idle for the set amount of time.
Session times out redirecting to login page
User enters credentials and is redirected back to where he was.
Now the above process is handled by passing a POST request passing the javax.faces.ViewState to the session management system. However, in case of timeouts it needs only 8K of data in the request to process and redirect. But since my managed bean is saving a lot of data (banking app, need to keep track of the calculations!) the size of the request is high (around 20K) due to which redirection fails.
So is there any way I can somehow save the ViewState? Or better, any way I can prevent the timeout? Something like keeping the session alive?
All my managed beans have a session scope.
EDIT: Just in case required, the javax.faces.STATE_SAVING_METHOD context-param in web.xml is set to client for performance purposes.
EDIT: Did a trace of the flow using HttpWatch and found out that javax.faces.ViewState is taking up 18kB of the total 22kB of size of the POST request. So my aim is narrowed down to reducing the size of ViewState. Any way to I can do this ?
State saving only keeps the data associated with the current view. Your problem here is that the session scoped beans are lost. I suggest two ways of solving the problem:
1) Implement a HttpSessionListener and in its sessionDestroyed() method get the beans, serialize them and store them in a database row associated with the current user. When the user logs in again you can fetch the beans, deserialize them and put them in the user's session.
2) Implement ajax poll that will ping the server in a specific period and this way the session will not timetout. You could achive this using Richfaces JSF library that has a built-in JSF component for ajax poll.
I migrated my webapp from Tomcat 5.5 to Tomcat 6(.0.32). In that app there are ajax calls in every footer page to avoid session timeout. It works fine on Tomcat 5.5 but it doesn't work in Tomcat 6. I use a filter to track every call in a DB table. On non-ajax calls I can see the tracking in the table and the reset session timeout. On ajax calls I can see the tracking in the table but not the reset of the session timeout.
Why? Can I change this behavior? And, just for info, how can Tomcat6 distinguish the ajax calls?
If you're not explicitly accessing the session in response to the AJAX calls, you may need to set the org.apache.catalina.STRICT_SERVLET_COMPLIANCE system property. Of course, that may also impact other parts of your app. Another option would be to ensure that you do explicitly access the session...