Session Timeout

[rle125]

SmartGWT 13.0p / Firefox 128

We defined a session timeout in web.xml and through a Filter, we're able to see incoming requests with that value (HttpSession.getMaxInactiveInterval()). However, we are also seeing certain requests with a value of 120 seconds, such as https://.../sc/DatasourceLoader. This results in premature logout while the operator is still using the application. Is there a SmartGWT setting that is being applied? Or is this coming from a browser setting?

[Isomorphic]

That's very strange, and we cannot come up with any mechanism in our software that would do this.

Just to confirm: you're seeing that specifically for DataSourceLoader, 120 seconds after the session has been established you're seeing that attempts to access that page are.. perhaps redirected to a login page? Or what specifically?

[rle125]

There are a couple other URLs that have the 120 second timeout:

.../sc/messaging
.../sc/IDACall
.../*.cache.js
.../loadScriptTagFiles.js
.../sc/skins/Enterprise/images/Dialog/warn.png

Our Filter checks the last access time against the timeout and invalidates the session if the timeout is exceeded, effectively logging them out.

[Isomorphic]

That's an odd collection of URLs, with not much in common from the perspective of our technology. And then, we don't supply an authentication system so it's quite bizarre that you would have this problem scoped to file that come from our framework.

Can you explain about the "Filter" - what is it, Spring, something else OTS, or your own custom code?

[rle125]

It's a custom class that implements Filter.doFilter(). If it isn't SmartGWT, maybe something with the browser.

[Isomorphic]

Got it. Ok, this isn't to do with our software, but we will throw out some guesses that might be helpful:

1. You could use logging in the Filter to capture stack traces when a new session is created (HttpServletRequest.getSession(true)).

2. the "120 seconds" number is very easy to search for. You could look for it across all of your config files and all of your Java source, and maybe hit something that will make sense of the situation

3. there could be a load balancer or reverse proxy involved (maye nginx)? It might strip out session tokens for some reason, related to caching, perhaps.

4. perhaps the requests involved are cross-site CORS requests because you're using a CDN to host static files? If so, the session for the CDN might be configured differently than the session for the app itself