Opened 11 years ago

Closed 10 years ago

#22800 closed Bug (fixed)

FormWizards leak data into other forms.

Reported by: Daniel Samuels Owned by: nobody
Component: contrib.formtools Version: 1.6
Severity: Normal Keywords:
Cc: daniel.samuels1@…, Florian Apolloner, mail@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Change History (7)

comment:1 by Sasha Romijn, 11 years ago

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?

comment:2 by Daniel Samuels, 11 years ago

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.

comment:3 by Florian Apolloner, 10 years ago

Cc: Florian Apolloner added
Triage Stage: UnreviewedAccepted

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.

comment:4 by Daniel Samuels, 10 years ago

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.

comment:5 by Florian Apolloner, 10 years ago

Right, that should suffice for most usecases!

comment:6 by Raphael Michel, 10 years ago

Cc: mail@… added

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.

comment:7 by Greg Chapple, 10 years ago

Resolution: fixed
Status: newclosed

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!

Note: See TracTickets for help on using tickets.
Back to Top