javaserverfaces-spec-public
  1. javaserverfaces-spec-public
  2. JAVASERVERFACES_SPEC_PUBLIC-1173

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

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Flow
    • Labels:
      None

      Description

      > 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.

        Activity

          People

          • Assignee:
            Unassigned
            Reporter:
            Ed Burns
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: