Reduce impact of people pressing back button

[phavekes]

This issue is imported from pivotal - Originaly created at Feb 26, 2019 by Thijs Kinkhorst

The back buttons have already been removed from all error pages. This might be a NOOP.

However people can still navigate back in history by using their browser back button, and that might be the actual/original scope of this story?

In that case, we could investigate if we can clear or modify the browser history. We should make an overview of the error situations an what would be expected back button behavior in those specific cases. For example, when you get the session-lost message you might want to re-visit your SP to again initiate your AuthNRequest. But for example, when a clock sync issue was raised, you want to stay at the error page.

Estimation: unable to estimate

[phavekes]

@thijskh @pmeulen @bartgeesink Can you elaborate on the original intention of this ticket? And maybe hint on the priority of this feature? (Michiel Kodde - May 2, 2019)

[phavekes]

Yes, this issue is about the back button and history functionality that is offerd by the user\'s webbrowser. It is not about the "back" link that EB used to have. This is a research question. We could timebox it.

We're under the impression that users use the back button to e.g. get back to their SP, to retry a failed login or resolve an error they get. This is hard to measure. The impression is based on the number of "HTTP Request that should not happen" that we see.

My question is what can we do here? Could we, for instance:

• Block returning to certain pages using the back button?
• Make it visible in the HTTP Request that it was the result of using the back button?

Other ideas or options? (Pieter van der Meulen - May 2, 2019)