NoSuchFlowExecutionException Errors
John Watt
John.Watt at glasgow.ac.uk
Mon Feb 16 11:04:22 UTC 2026
*
By the time you see a 500 result on one of the bad calls, the idp has
already processed it? I'm not sure what fix could be done after it
happens, short of dynamically blocking the IP so it doesn't make another
request.
Disclaimer: I present the following as the output of a conversation with AI for information only. We haven't tested this as it doesn't affect out day-to-day operation, and we haven't deployed, nor recommend deploying it, in production! If we do get around to investigating this more fully I'll update..
It seems to think that Safari WebKit is hammering retries in the background because it's getting 500 responses on that execution URL, so it proposes using the REDIRECT_STATUS to detect that 500 so it can issue a clean 302 on that URL and WebKit will stop retrying.
RewriteCond %{REQUEST_METHOD} GET
RewriteCond %{REQUEST_URI} ^/idp/profile/SAML2/Redirect/SSO$
RewriteCond %{QUERY_STRING} (^|&)execution=
RewriteCond %{REDIRECT_STATUS} =500
RewriteRule ^ /idp/profile/SAML2/Redirect/SSO [R=302,L]
Again, we have no idea if this actually works for this issue as we can't reproduce it other than on a production node as it's actually happening in the wild. Based on the few incidents we have looked at it appears to be non-malicious behaviour of a Safari user agent, and probably wouldn't solve anything else (e.g. bot etc..), and possibly introduces unintended consequences elsewhere.
________________________________
From: users <users-bounces at shibboleth.net> on behalf of Paul B. Henson via users <users at shibboleth.net>
Sent: 14 February 2026 03:56
To: users at shibboleth.net <users at shibboleth.net>
Cc: Paul B. Henson <henson at acm.org>
Subject: Re: NoSuchFlowExecutionException Errors
On 2/13/2026 1:33 AM, John Watt via users wrote:
> Safari WebKit and has provided a fix for our Apache config involving
> mod_rewrite on "execution" flows that return a 500 - it doesn't seem to
By the time you see a 500 result on one of the bad calls, the idp has
already processed it? I'm not sure what fix could be done after it
happens, short of dynamically blocking the IP so it doesn't make another
request.
--
For Consortium Member technical support, see https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth.atlassian.net%2Fwiki%2Fx%2FZYEpPw&data=05%7C02%7CJohn.Watt%40glasgow.ac.uk%7Cb0b242f9fa10443dc92108de6b7d20b5%7C6e725c29763a4f5081f22e254f0133c8%7C1%7C0%7C639066382334070861%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VnQ%2FMziodsNC23i346YLLyO%2FWKE8BOlCToy4NqzKU2w%3D&reserved=0<https://shibboleth.atlassian.net/wiki/x/ZYEpPw>
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20260216/12acc54a/attachment.htm>
More information about the users
mailing list