FormWizard has a security_hash check failure with Textareas with leading/trailing newlines in Safari

[Dana Spiegel]

I have a Form with a TextField, and when I put this form into a FormWizard, the security_hash generated for that form is different before/after the next form is submitted. This only happens on Safari. I've traced the issue to a TextField that has leading and/or trailing newlines.

In Firefox, a Textarea is apparently stripped upon submission, but in Safari, the leading/trailing newlines are submitted. As a result, when submitting the form with the Textarea, the security_hash that is generated uses the value of the field with the newlines included. But when I submit the next form, the security_hash that is generated from the previous fields doesn't have the newlines in that field's value. As a result, the security_hash is different, generating a security_hash failure. This may be due to the way that the previous fields are rendered into the second form.

[Kevin Kubasik]

I have no idea if this patch actually fixes it, but it seems like it might.

[Jacob]

(In [10752]) Fixed #10034: the formtools security hash function is now friendlier to browsers that submit leading/trailing whitespace in form fields.

[al@…]

In v1.0: This fix doesn't work; The latest Safari is not only passing in leading/trailing whitespace - it is also passing through \r\n within the fields. These are blowing up the hashing algorithm.

The tests need to add:

f1 = TestForm({'name': 'joe', 'bio': 'Nothing\r\nnotable.'})

Adjusting fix 10752 (django/contrib/formtools/utils.py) as follows works:

25:  if isinstance(value, basestring):
26:    value = value.strip()
27+    value = value.replace('\r', ' ')
28+    value = value.replace('\n', ' ')

[Karen Tracey]

Replying to al@webreply.com:

In v1.0: This fix doesn't work; The latest Safari is not only passing in leading/trailing whitespace - it is also passing through \r\n within the fields. These are blowing up the hashing algorithm.

What you are describing is a new problem: there was no mention of embedded \r\n previously in this ticket. Please open new tickets for new problems.

Also please be clear about the version you are referring to. The fix for this ticket went into trunk and the 1.0.X branch in May, thus is available in 1.1 and 1.0.3. I don't know what you mean when you say "In v1.0"; if this behavior was broken in 1.0 it will stay broken in 1.0 forever -- the fix is only available in an update to the release.

[Jacob]

Milestone 1.1 deleted