Handle gracefully the case of a link to flow based page copied to new browser tab

> LU> Hi
> LU> I have been checking the proposal for OutcomeTarget navigation in deep. In few
> LU> words, the critical point is what clientWindowTransition() should do and how
> LU> to encode GET links properly.
>
> LU> Let's consider again this use case :
>
> LU> (suppose the flow document id is flowDoc2)
>
> LU>
> LU>
> LU>
> LU> exit1
> LU>
> LU>
> LU>
>
> LU> (suppose the flow document id is flowDoc1)
>
> LU>
> LU>
> LU>
> LU> mainpage
> LU>
> LU>
> LU>
>
> LU> Suppose we are in /flow2/mypage.xhtml and there is a link to exit the flow. How
> LU> it should looks like? according to what I can deduct from the spec it should
> LU> be something like this:
>
> LU> [http://localhost:8080/myapp/mainpage.xhtml?jffi=exit2&jftfdi=flowDoc2](http://localhost:8080/myapp/mainpage.xhtml?jffi=exit2&jftfdi=flowDoc2)
>
> LU> In theory the link should work as long as the flow stack is:
>
> LU> flow2
> LU> flow1
> LU> root
>
> LU> But what happen if I copy the link into a new browser tab?
>
> That is not supposed to work because, by definition, the flow system is
> entirely built on ClientWindow, which, by definition is bound to a
> browser view (such as a tab or window).
>

Yes, I know it does not work, it should not work, but the problem is how faces
flow fails under such circumstance.

When this could happen? a session expiration is a good example. Since there
is no ViewState, there will not be ViewExpiredException, and the link will be
sent by the user without notice.

The point is if that scenario happens (which is probably), faces flow should be
able to recognize the situation with a simple check and do something like
throw an exception or exit the flow.

Other situation when this is relevant is what happen if you hit the same link
twice. The first time it gets out of the flow, but the second time you
are already
out. Again it is up to the user detect that kind of failure doing its
own logic to
check if the request is valid, but faces flow could do it for you just checking
one query param.

In a previous conversation, it was mentioned that "... a flow has a single front
door ..." and that it has "... well defined entry and exit points
...". My concern
here is that theorically it is possible to enter into a flow without go through
the start node, and there are simple exit cases with "unknown" results.

Start with the clientWindowTransition() behavior described in the issue and trace how the jffi and jftfdi query parameters are handled for flow exits. Reproduce a copied link after session expiration and a link used twice, then define and verify graceful handling for invalid or already-exited flows.

Written by the indexing model from the issue text.