It was understood at the time that that's subject to manipulation by the client to control a state transition within a flow, and the flows we supplied were not subject any significant problems because they couldn't be subverted to do anything useful, but third parties have created extensions that do have problems because this wasn't documented as a risk, and it's a bad idea anyway.
One of the side effects of this trick was that it made flow authoring much simpler, since it allowed lots of error states to be handled with one rule.
We should get rid of these rules if we can, but it may need to be done for the time being in a more indirect way by possibly enumerating the states to permit transitions on. Depending on the fix, this might be a patch issued sooner. If not, an advisory is warranted to explain some of the risk.
Some of the extension points in the system rely on abstract flows containing global transitions of the form:
<transition on="#{!'proceed'.equals(currentEvent.id)}" to="#{currentEvent.id}" />It was understood at the time that that's subject to manipulation by the client to control a state transition within a flow, and the flows we supplied were not subject any significant problems because they couldn't be subverted to do anything useful, but third parties have created extensions that do have problems because this wasn't documented as a risk, and it's a bad idea anyway.
One of the side effects of this trick was that it made flow authoring much simpler, since it allowed lots of error states to be handled with one rule.
We should get rid of these rules if we can, but it may need to be done for the time being in a more indirect way by possibly enumerating the states to permit transitions on. Depending on the fix, this might be a patch issued sooner. If not, an advisory is warranted to explain some of the risk.