<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, "EmojiFont", "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;">
<p>Hi All,<br>
</p>
<p><br>
</p>
<p>We recently upgraded our Shibboleth instance to a cluster of Shibboleth Docker containers. After the update, some users started receiving the error that you get when you hit the back button in the web browser:</p>
<p><br>
</p>
<p></p>
<div> 2017-11-15 16:05:13,213 - ERROR [org.springframework.webflow.execution.repository.NoSuchFlowExecutionException:76] -<br>
org.springframework.webflow.execution.repository.NoSuchFlowExecutionException: No flow execution could be found with key 'e1s1' -- perhaps this executing flow has ended or expired? This could happen if your users are relying on browser history (typically
via the back button) that references ended flows.<br>
at org.springframework.webflow.execution.repository.support.AbstractFlowExecutionRepository.getConversation(AbstractFlowExecutionRepository.java:172)<br>
Caused by: org.springframework.webflow.conversation.NoSuchConversationException: No conversation could be found with id '1' -- perhaps this conversation has ended?<br>
at org.springframework.webflow.conversation.impl.ConversationContainer.getConversation(ConversationContainer.java:126)<br>
<br>
</div>
We have had a hard time replicating this error because it only seems to happen the first time a user attempts to log in to one of our SPs from a new computer. All subsequent login attempts on their machine work. The user will:
<p></p>
<p><br>
</p>
<ol style="margin-bottom:0px; margin-top:0px">
<li>Sign into a new computer</li><li>Attempt to log in to one of the SPs</li><li>The log in will fail with the error message above</li><li>The user generally will then try to access the SP again, get another prompt to log in and then successfully access the service</li><li>Any subsequent attempts to log in to Shibboleth on their machine work as intended</li></ol>
<p><br>
</p>
<p><span>We've tried to replicate this by clearing the browser cache/cookies/history, but that doesn't replicate the issue. Is it possible that the failure has to do with a cookie which was set by the previous IDP configuration?</span></p>
<p><span><br>
</span></p>
<p>Some other notes about our cluster:<br>
</p>
<ul style="margin-bottom: 0px; margin-top: 0px;">
<li>We are using Traefik for load balancing the IDP containers, sticky sessions are enabled, and it appears as though failures are still occurring if we take one of the instances offline.</li><li>All of our IDP containers share the same database for SLO and LDAP</li><li>We haven't changed any of the credentials such as the cookie encryption key.</li><li>This seems to be happening for all of our SPs.<br>
</li></ul>
<p><br>
</p>
<p>Does anyone know what might be causing this? Any suggestions for replicating the problem without having to log in to a new computer would be greatly appreciated as well.<br>
</p>
<p><br>
</p>
<div id="Signature">
<div id="divtagdefaultwrapper" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Arial,Helvetica,sans-serif,"EmojiFont","Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<p>Thanks,<br>
</p>
<p> David Newswanger</p>
</div>
</div>
</div>
</body>
</html>