Back button issue

[Lee, Dong]

Thank you for your response.

Yes, we sometimes see the issue you mention and guide users with the correct URLs. The users we assist experience intermittent back button errors frequently enough to hinder their daily tasks or studies, prompting them to submit a service ticket. According to their descriptions, they encounter the back button error two or three times regularly before successfully logging in. Some users report this happening the first time they try to log in each morning, while others find that only incognito or private browsing mode allows them to log in. We are reaching out to individual users to collect data on their usage patterns (on-campus or off-campus, browser versions, etc.).

In general, if you visit a Shibboleth-protected website and encounter a back button error, what conditions could trigger this error?
In two scenarios:

  1.  You closed all the browser instances and started a new web browser session. (Is this even possible?)
  2.  You have other tabs open and type the Shibboleth-protected URL in a new or existing tab.


Dong Lee

Identity Management & System Integration
Center for Information Technology Services
University of Maryland, Baltimore
410-706-3027
dlee at umaryland.edu<mailto:dlee at umaryland.edu>


From: users <users-bounces at shibboleth.net> On Behalf Of IAM David Bantz via users
Sent: Thursday, January 30, 2025 2:52 PM
To: Shib Users <users at shibboleth.net>
Cc: IAM David Bantz <dabantz at alaska.edu>
Subject: Re: Back button issue

CAUTION: This message originated from a non-UMB email system. Hover over any links before clicking and use caution opening attachments.
You did note that, in addition to users attempting to use the browser "back" button, that the same error can be triggered by using a cached, bookmarked, or other incorrect URL. I've observed many attempts to grab the URL displayed in the browser during a sign-in sequence, typically of the form:
https://myidp.myu.edu/idp/profile/SAML2/POST/SSO?execution=e1s1
which is, of course, not a proper request initiator.

A frustrating variant we've noticed occurs when users have relied on a google search for the intended resource URL, and for whatever reason, the google result is not in fact the proper URL to initiate sign-in.

All to say you want to ensure your users are initiating the SSO sign-in from the proper functioning URL, not relying on any other process to guess a starting URL. If attempting to resolve a user's issue, they and you need to know exactly what was entered in the address box or what link was clicked on, and not rely on a displayed address(es) intermediate in the sign-in process.

David St Pierre Bantz
U Alaska IAM

On Thu, Jan 30, 2025 at 10:27 AM Lee, Dong via users <users at shibboleth.net<mailto:users at shibboleth.net>> wrote:
Hi,

We have observed an uptick in reports from users receiving the following error message. They report not clicking the back button, and some also report this being their first login attempt of the day.

Error Message to Users:
You may be seeing this page because you used the Back button while browsing a secure web site or application. Alternatively, you may have mistakenly bookmarked the web login form instead of the actual web site you wanted to bookmark or used a link created by somebody else who made the same mistake.
Left unchecked, this can cause errors on some browsers or result in you returning to the web site you tried to leave, so this page is presented instead.

Log Entry:
ERROR [net.shibboleth.idp.authn.ExternalAuthenticationException:91] – x.x.x.x - net.shibboleth.idp.authn.ExternalAuthenticationException: Error retrieving flow conversation
        at net.shibboleth.idp.authn.ExternalAuthentication.getProfileRequestContext(ExternalAuthentication.java:227)
Caused by: org.springframework.webflow.execution.repository.NoSuchFlowExecutionException: No flow execution could be found with key 'e1s2' -- 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.
        at org.springframework.webflow.execution.repository.support.AbstractFlowExecutionRepository.getConversation(AbstractFlowExecutionRepository.java:172)
Caused by: org.springframework.webflow.conversation.NoSuchConversationException: No conversation could be found with id '1' -- perhaps this conversation has ended?
        at org.springframework.webflow.conversation.impl.ConversationContainer.getConversation(ConversationContainer.java:126)

Here are some questions:

  1.  Is the error message associated with the error in the log?
  2.  What do I need to look at, or where should I look, on the IDP servers? We have three servers behind a load balancer in Azure.
  3.  When working with users, we recommend clearing all browser cookies and caches. However, this does not resolve the issue.

To be honest, I’m not sure what questions I should ask. If I find something in the response that matches our situation, I will post more specific follow up questions.

Thank you,
Dong Lee

Identity Management & System Integration
Center for Information Technology Services
University of Maryland, Baltimore
410-706-3027
dlee at umaryland.edu<mailto:dlee at umaryland.edu>


--
For Consortium Member technical support, see https://shibboleth.atlassian.net/wiki/x/ZYEpPw
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20250131/81f72a49/attachment.htm>