[Django] #22800: FormWizards leak data into other forms.
Django
-----------------------------------+--------------------
Reporter: danielsamuels | Owner: nobody
Type: Bug | Status: new
Component: contrib.formtools | Version: 1.6
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+--------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22800>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: danielsamuels | Owner: nobody
Type: Bug | Status: new
Component: contrib.formtools | Version: 1.6
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by erikr):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
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?
--
Ticket URL: <https://code.djangoproject.com/ticket/22800#comment:1>
Django
Reporter: danielsamuels | Owner: nobody
Type: Bug | Status: new
Component: contrib.formtools | Version: 1.6
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by danielsamuels):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22800#comment:2>
Django
Reporter: danielsamuels | Owner: nobody
Type: Bug | Status: new
Component: contrib.formtools | Version: 1.6
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by apollo13):
* cc: apollo13 (added)
* stage: Unreviewed => Accepted
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22800#comment:3>
Django
Reporter: danielsamuels | Owner: nobody
Type: Bug | Status: new
Component: contrib.formtools | Version: 1.6
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by danielsamuels):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22800#comment:4>
Django
Reporter: danielsamuels | Owner: nobody
Type: Bug | Status: new
Component: contrib.formtools | Version: 1.6
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by apollo13):
Right, that should suffice for most usecases!
--
Ticket URL: <https://code.djangoproject.com/ticket/22800#comment:5>
Django
Reporter: danielsamuels | Owner: nobody
Type: Bug | Status: new
Component: contrib.formtools | Version: 1.6
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by raphaelm):
* cc: mail@… (added)
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22800#comment:6>
Django
Reporter: danielsamuels | Owner: nobody
Type: Bug | Status: closed
Component: contrib.formtools | Version: 1.6
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by gchp):
* status: new => closed
* resolution: => fixed
Comment:
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!
--
Ticket URL: <https://code.djangoproject.com/ticket/22800#comment:7>