Formhandler

Reinhard Führicht wrote:

as mentioned in several issues before, this feature was removed due to security reasons.

I can't imagine a real security reason why to absolutly block this. A random-token always is good work, in my opinion I wouldn't get rid off. But I can't realize where this could become a security risk, giving the site-admin the option to jump between all available steps.

Simple case: This could be used for a flexible steps-bar giving the user the option to switch from Step 3 back to Step 1 (=already filled). A jump to the next unfinished Step (f.e. Step 4) should be impossible anyway to make shure the right order of multi-step forms is working.

If you think this is a security problem, why can't you provide a optional interceptor class checking if there is a jump-stage called by the form? This class could also cover checking for the last valid randomID and renewing it (as neccesary?) for the called step.

It's a security problem to jump ahead e.g. from step 1 to step 4. Then it is difficult to deal with the error checks having to be called.
The same problem is when the user is allowed to jump back and then jumps forward again.

Formhandler would have to save the "validation state" of each step of the form to find out if the user is allowed to jump to a specific step or not. Allthough this might be possible, I don't have a good feeling about that.

Furthermore, the calculation of the current step is currently done in the controller and I think it cannot be moved to an interceptor because the step is needed for loading the right interceptors.

Reinhard Führicht wrote:

It's a security problem to jump ahead e.g. from step 1 to step 4. Then it is difficult to deal with the error checks having to be called. The same problem is when the user is allowed to jump back and then jumps forward again.

Well, ok that's absolutely right as I already stated that jumping to a "future" step doesn't make sense anyway and should be disallowed.

But I don't think that steps that already have been passed will break a lot. All validation-checks should already been done then - else you would not be able to pass f.e. from Step 1 to Step 2. So jumping back to Step 1, then forward again to Step 2 should be not a big problem. If some inputs have changed and don't validate in Step 1, then of couse this should give the user the ability to correct them. But all completed steps are kept in session, right? So I think there should be no problem there.

The only thing that may be neccessary (in some special cases) would be to re-call preProcessors for the next Step (in the example this would be Step 2 in the second run). The session-values should be kept as default fallback and it would be useful to have a register to signal that this step has been passed once before. Alternatively a TS-Flag defining if the preProcessor-Value should be overwritten again after coming back would be useful. This is simply just similary to the updateOrInsert Flag used in the Finisher_DB.

Gabriel Kaufmann / Typoworx NewMedia wrote:

But I don't think that steps that already have been passed will break a lot. All validation-checks should already been done then - else you would not be able to pass f.e. from Step 1 to Step 2. So jumping back to Step 1, then forward again to Step 2 should be not a big problem. If some inputs have changed and don't validate in Step 1, then of couse this should give the user the ability to correct them. But all completed steps are kept in session, right? So I think there should be no problem there.

Jumping through the steps can cause big problems. Imagine the following:

• A form consists of 4 steps
• The visible fields can vary depending on the user input.

If a user jumps back from step 4 to step 1 and changes a value, then the user must not be allowed to jump back to step 4 again, but only to step 2.

So i am willing to integrate the possibility to jump back to any step, but moving forward will always be one step at a time.

OK: step 4 -> step 2
NOT OK: step 2 -> step 4

Reinhard Führicht wrote:

So i am willing to integrate the possibility to jump back to any step, but moving forward will always be one step at a time.

OK: step 4 -> step 2 NOT OK: step 2 -> step 4

Well I agree with you that there may be cases that are not easy to handle with this feature. The TYPO3-Integrator should decide either to use or not to use the feature (depending on the situation it makes sense or not).

I also agree that jumping to unfinished step's is NOT OK and does not make any sense.

After integrating the jump-back feature to any of the passed steps, you should add some notes regarding possible problem-situations in your documentation of this feature.