4

I have a grails 4 (based on spring boot) application that is experiencing sporadic failures. At this point I cannot find anything even pointing to what the problem may be, and hope that perhaps someone can assist.

The scenario where the error occurs is one application making a REST call to another. These are all made with a common username and password provided via basic authentication. At some point after the application has been running successfully (> 12 hours in most cases seen so far) these calls begin to fail with this error:

org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.IllegalStateException: UT000010: Session is invalid XVBnzVaxVhijSIz2xk_Tl5fqsJD9n30ggd_614iF
        at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1014)
        at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:898)
        at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:883)
        at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
        at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:209)
        at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:178)
        at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
        at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
        at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
        at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
        at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
        at io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:251)
        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:186)
        at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:501)
        at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:427)
        at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:308)
        at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
        at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
        at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
        at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
        at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
        at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
        at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
        at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalStateException: UT000010: Session is invalid XVBnzVaxVhijSIz2xk_Tl5fqsJD9n30ggd_614iF
        at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:512)
        at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:122)
        at org.springframework.web.servlet.support.SessionFlashMapManager.retrieveFlashMaps(SessionFlashMapManager.java:49)
        at org.springframework.web.servlet.support.AbstractFlashMapManager.retrieveAndUpdate(AbstractFlashMapManager.java:94)
        at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:934)
        at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)

Calls to the same endpoint with the same basic authentication from Postman succeed.

For these calls, security is configured as such:

  http
    .headers().frameOptions().sameOrigin().and()
    .csrf().disable()
    .requestMatcher(basicAuthMatcher)
    .authorizeRequests()
    .anyRequest().authenticated()
    .and()
    .httpBasic()
     
  http.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)

The parts that are suspicious to me are that the stack trace is coming out of SessionFlashMapManager. To my understanding there should be no session. There certainly is none that I intend to use.

Has anyone seen errors like this before, or have suggestions for how to diagnose it?

Daniel
  • 3,312
  • 1
  • 14
  • 31
  • how did you get around this issue – Alec Sep 13 '22 at 12:34
  • The only git commit i have in or around this code in that timeframe was to remove the STATELESS line. I do recall that we added preemptive authentication (including it in the headers) for POST calls around this same time, as it turned out that timeouts on very large POSTs were killing off the authentication request itself. That's probably unrelated to this issue but wanted to mention it in case my memory is wrong! Good luck! – Daniel Sep 13 '22 at 16:22
  • Per my previous comment, preemptive authentication can be a security hole if done incorrectly. If you end up needing to add it, be careful to only send to endpoints that you control. – Daniel Sep 13 '22 at 16:29

0 Answers0