Just as a possibly related piece of work:

http://forum.spring.io/forum/spring-projects/web/web-flow/119955-spring-webflow-2-working-with-persistent-conversation-data

The back button behavior that actually is bothering me is that SWF doesn't honor the history list, it's re-rendering an error and essentially going "forward" again into an error so that the back button just traps you.

I'm planning to look at implementing some kind of Javascript in the error view for this error condition that tries to move back in the history list or at least presents a link to do that.

I don't actually want the back button to ever work, that's incompatible with the SSO protocols the IdP supports.

Since you mentioned a desire for better back-button handling, I'll throw this out:

https://github.com/serac/spring-webflow-client-repo

It's the opposite of what you're trying to do and admittedly infeasible for the large, complex flows of the IdP, but it does work well for some cases. The driving force for me was session timeouts breaking the login flow in CAS, which was a pain case for us. I would argue we got better back-button behavior as a side-effect.

Is this related to ? Or does it supersede it?

Pushing this to post-3.0 for now. I'm very unhappy with the back button handling in SWF, but I don't know that it will be much better regardless of what we do, and I don't know that we could really manage to implement anything.

We're not going to snapshot the context tree, and allowing flows to go backwards without resetting the tree's state seems very dangerous at best and catastrophic at worst.