FormWizards leak data into other forms.

[Daniel Samuels]

Consider an events booking system where someone selects their tickets, adds their payment information but then decides to navigate away on the last page. If they then went to a different event all of their payment information etc would be shown as the initial data in the new form, even though it's on a completely different URL with completely different content. This really shouldn't be happening. It would be useful to limit the form data to a specific form, either by URL or by some sort of form hash which is different for each form.

[Sasha Romijn]

I'm not entirely following what you mean. If I understand correctly, the issue you have is that if a user returns to the same FormWizard at a later time, their data is still in the form? Could you provide an example of the issue?

[Daniel Samuels]

The same FormWizard, but in a different context. Say for example you have a form where you enter your address information for a specific item, so your URL is /item/4/form/, you then go to /item/5/form/ which technically is the same FormWizard - but for a different item - the information you entered in the first form, if you didn't complete it, will be displayed on the 2nd form even though you've never been to that page before. So it's the same FormWizard used in different contexts, but the data from one appears in the other.

[Florian Apolloner]

Jupp, this is the result of ​https://github.com/django/django/blob/master/django/contrib/formtools/wizard/views.py#L195-L197 -- a quick workaround would be to create a subclass in the view which includes the ID :( If you'd like to work on a real fix I think we should add a random hash to it and send it along via the management form.

[Daniel Samuels]

What about being able to provide an instance specific key? I know in my situation I could have provided the event ID as the 'salt', I'm sure it would be fairly trivial for most people to provide a value which is instance specific.

[Florian Apolloner]

Right, that should suffice for most usecases!

[Raphael Michel]

Is there really a change to Django necessary? Daniel could just override get_prefix in his view and return a prefix based on his event ID. I just thought about how I'd design an API to provide an "instance specific key", als you put it, and what I came up with was exactly what get_prefix already is.

If you think there should be another way to do this, I'd like to work on this as my first contribution to Django itself, as I will have the same use case in one of my current projects.

[Greg Chapple]

formtools has been extracted into its own repository (​https://github.com/django/django-formtools/). Because of this, the issue tracking for this package has been moved to GitHub issues. I'm going to close this ticket, but I've created a GitHub issue to replace it where the conversation can continue: ​https://github.com/django/django-formtools/issues/15. Thanks!