NoSuchFlowExecutionException Errors

[Paul B. Henson]

On Fri, Feb 13, 2026 at 02:56:20AM +0000, Hall, Gerry via users wrote:

> Has anyone else experienced this issue, and if so, did you determine a
> solution?

This happens when a request shows up that needs state to be processed,
but there is no such state. Taking CAS for example, an initial request
might be:

https://idp.cpp.edu/idp/profile/cas/login?service=https://my.cpp.edu/uPortal/Login

No state is required for this call, but it creates state. As the CAS
request is processed back and forth between the browser and the server,
additional calls are made:

https://idp.cpp.edu/idp/profile/cas/login?execution=e1s1
https://idp.cpp.edu/idp/profile/cas/login?execution=e1s2
https://idp.cpp.edu/idp/profile/cas/login?execution=e1s3

The eXsX parameter is the Spring Web Flow execution key which defines
what step of the process the call involves. When you properly start a
request which makes state and then make follow up requests that require
state, it knows what to do.

OTOH, if out of the blue with no state you just call
https://idp.cpp.edu/idp/profile/cas/login?execution=e1s1, it fails with
the error you're seeing. This can happen when a valid user hits the back
button in their browser and re-executes a call whose state has expired.
It can also happen when stupid idiot bots blindly follow URLs they don't
understand 8-/.

The past week or so I've been getting hundreds of thousands of calls a
day to https://idp.cpp.edu/idp/profile/cas/login?execution=e1s1 from
various IP addresses in Fastly, Cloudflare, AWS, and other places where
users don't generally live. I'm assuming it's an idiot bot, although
it's pretending to be a real user by spoofing the user agent <sigh>.

It hasn't been affecting the operation of the idp too much other than
it was filling up my log partition as each call generates a huge
backtrace in idp-warn.log.

There's not much to be done at the idp level, you can't keep people from
making the requests, and that's just what the idp does when it gets
them. The only real option is to shortcut the request at the jetty level
and keep it from getting to the idp, that minimizes the resources it can
suck up.

If the request includes a session cookie, there's no way to find out if
it's valid without passing through to the idp. But most stupid bots
aren't going to have a session cookie set when they make an invalid
call, so you can check for a URL that requires state, and if it doesn't
have a session cookie, return a 403.

Unfortunately jetty didn't include a way to do that (well, without
coding a custom java filter and adding a jar), so I ended up submitting
a new rewrite rule:

	https://github.com/jetty/jetty.project/pull/14488


With this rule, you can do something like this:

        <!-- refuse calls to URLs that require a session when there's no
session cookie -->
        <Call name="addRule">
          <Arg>
            <New class="org.eclipse.jetty.rewrite.handler.RuleContainer">
              <Call name="addRule">
                <Arg>
                  <!-- jetty is feature-poor as far as boolean operations on rules, so we
                       kludge a regex that matches everything but what we want to match -->
                  <New class="org.eclipse.jetty.rewrite.handler.TerminatingRegexRule">
                    <Set name="regex">^(?!/idp/profile/cas/login\?execution=).*$</Set>
                  </New>
                </Arg>
              </Call>
              <Call name="addRule">
                <Arg>
                  <New
class="org.eclipse.jetty.rewrite.handler.ResponseCookieValueRegexRule">
                    <Set name="cookieName">__Host-JSESSIONID</Set>
                    <Set name="negate">true</Set>
                    <Set name="code">403</Set>
                  </New>
                </Arg>
              </Call>
            </New>
          </Arg>
        </Call>


Any request for a URL with the prefix /idp/profile/cas/login?execution=
that doesn't include a __Host-JSESSIONID cookie immediately gets a 403.