Opened 16 years ago

Closed 16 years ago

Last modified 13 years ago

#8266 closed (duplicate)

Form composed entirely of BooleanFields fails FormWizard hash validation

Reported by: rokclimb15 Owned by: nobody
Component: contrib.formtools Version: dev
Severity: Keywords: FormWizard
Cc: rokclimb15@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


FormWizard's call method checks the hash of the previous forms against the key in the POST data. If you use a form entirely composed of BooleanFields, it will fail the hash check. I think this is because the raw POST data sets the field to 'on', while the BF normalizes this data to True.

Here is a dump of my POST data. The hash for all 1-x values is deb9fcbe6ea61734b57d7107146a73a7. You can see in the POST data it was expecting f14a8cc9fbac45395d96d2e4096b7b79. I think the previous value was being generated based on raw POST data and not boundfield values.

1-9  	u'False'
wizard_step u'2'
1-15 	u'False'
1-14 	u'False'
1-17 	u'False'
0-type 	u'Wedding'
1-11 	u'False'
1-10 	u'False'
1-13 	u'False'
1-12 	u'False'
0-take_requests u'Yes'
1-18 	u'False'
hash_1 	u'f14a8cc9fbac45395d96d2e4096b7b79'
hash_0 	u'edc21eaca82256ba02b38e7a4e7f07c4'
0-special_requests u''
0-email 	u''
1-8 	u'False'
2-1 	u'on'
1-1 	u'False'
1-3 	u'on'
1-2 	u'on'
1-5 	u'False'
1-4 	u'False'
1-7 	u'False'
1-6 	u'False'
0-date 	u'08/12/2008'
0-name 	u'Brian Morton'
0-interaction_level 	u'Reserved'
1-16 	u'False'
0-location 	u'Atlanta'

Change History (3)

comment:1 by Jacob, 16 years ago

milestone: 1.0
Triage Stage: UnreviewedAccepted

comment:2 by Alex Gaynor, 16 years ago

Resolution: duplicate
Status: newclosed

This looks to be a dupe of #6209.

comment:3 by Jacob, 13 years ago

milestone: 1.0

Milestone 1.0 deleted

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