Form composed entirely of BooleanFields fails FormWizard hash validation
|Reported by:||rokclimb15||Owned by:||nobody|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||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 firstname.lastname@example.org' 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 Changed 8 years ago by jacob
- milestone set to 1.0
- Needs documentation unset
- Needs tests unset
- Patch needs improvement unset
- Triage Stage changed from Unreviewed to Accepted