[JAVASERVERFACES_SPEC_PUBLIC-1173] Handle gracefully the case of a link to flow based page copied to new browser tab Created: 16/Mar/13  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


> 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> <faces-flow-definition id="flow2">
> LU> <flow-return id="exit2">
> LU> <navigation-case>
> LU> <from-outcome>exit1</from-outcome>
> LU> </navigation-case>
> LU> </flow-return>
> LU> </faces-flow-definition>
> LU> (suppose the flow document id is flowDoc1)
> LU> <faces-flow-definition id="flow1">
> LU> <flow-return id="exit1">
> LU> <navigation-case>
> LU> <from-outcome>mainpage</from-outcome>
> LU> </navigation-case>
> LU> </flow-return>
> LU> </faces-flow-definition>
> 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
> 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.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor

Generated at Mon Jan 16 22:25:45 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.