Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
import os
|
|
|
|
|
2010-12-04 15:28:12 +08:00
|
|
|
from django import forms, http
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
from django.conf import settings
|
2010-10-11 20:55:17 +08:00
|
|
|
from django.contrib.formtools import preview, wizard, utils
|
2007-11-30 00:32:23 +08:00
|
|
|
from django.test import TestCase
|
2010-10-11 20:55:17 +08:00
|
|
|
from django.utils import unittest
|
2007-11-30 00:32:23 +08:00
|
|
|
|
|
|
|
|
2010-12-04 15:28:12 +08:00
|
|
|
success_string = "Done was called!"
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
|
2007-11-30 00:32:23 +08:00
|
|
|
class TestFormPreview(preview.FormPreview):
|
2010-11-21 21:47:38 +08:00
|
|
|
def get_context(self, request, form):
|
|
|
|
context = super(TestFormPreview, self).get_context(request, form)
|
|
|
|
context.update({'custom_context': True})
|
|
|
|
return context
|
|
|
|
|
|
|
|
def get_initial(self, request):
|
|
|
|
return {'field1': 'Works!'}
|
2007-11-30 00:32:23 +08:00
|
|
|
|
|
|
|
def done(self, request, cleaned_data):
|
|
|
|
return http.HttpResponse(success_string)
|
|
|
|
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
|
2007-11-30 00:32:23 +08:00
|
|
|
class TestForm(forms.Form):
|
|
|
|
field1 = forms.CharField()
|
|
|
|
field1_ = forms.CharField()
|
2008-08-27 04:19:12 +08:00
|
|
|
bool1 = forms.BooleanField(required=False)
|
2007-11-30 00:32:23 +08:00
|
|
|
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
|
|
|
|
class UserSecuredFormPreview(TestFormPreview):
|
|
|
|
"""
|
|
|
|
FormPreview with a custum security_hash method
|
|
|
|
"""
|
|
|
|
def security_hash(self, request, form):
|
|
|
|
return "123"
|
|
|
|
|
|
|
|
|
2007-11-30 00:32:23 +08:00
|
|
|
class PreviewTests(TestCase):
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
urls = 'django.contrib.formtools.tests.urls'
|
2007-11-30 00:32:23 +08:00
|
|
|
|
|
|
|
def setUp(self):
|
|
|
|
# Create a FormPreview instance to share between tests
|
|
|
|
self.preview = preview.FormPreview(TestForm)
|
|
|
|
input_template = '<input type="hidden" name="%s" value="%s" />'
|
|
|
|
self.input = input_template % (self.preview.unused_name('stage'), "%d")
|
2008-08-27 04:19:12 +08:00
|
|
|
self.test_data = {'field1':u'foo', 'field1_':u'asdf'}
|
2007-11-30 00:32:23 +08:00
|
|
|
|
|
|
|
def test_unused_name(self):
|
|
|
|
"""
|
|
|
|
Verifies name mangling to get uniue field name.
|
|
|
|
"""
|
|
|
|
self.assertEqual(self.preview.unused_name('field1'), 'field1__')
|
|
|
|
|
|
|
|
def test_form_get(self):
|
|
|
|
"""
|
|
|
|
Test contrib.formtools.preview form retrieval.
|
|
|
|
|
|
|
|
Use the client library to see if we can sucessfully retrieve
|
|
|
|
the form (mostly testing the setup ROOT_URLCONF
|
|
|
|
process). Verify that an additional hidden input field
|
|
|
|
is created to manage the stage.
|
|
|
|
|
|
|
|
"""
|
|
|
|
response = self.client.get('/test1/')
|
|
|
|
stage = self.input % 1
|
|
|
|
self.assertContains(response, stage, 1)
|
2010-11-21 21:47:38 +08:00
|
|
|
self.assertEquals(response.context['custom_context'], True)
|
|
|
|
self.assertEquals(response.context['form'].initial, {'field1': 'Works!'})
|
2007-11-30 00:32:23 +08:00
|
|
|
|
|
|
|
def test_form_preview(self):
|
|
|
|
"""
|
|
|
|
Test contrib.formtools.preview form preview rendering.
|
|
|
|
|
|
|
|
Use the client library to POST to the form to see if a preview
|
|
|
|
is returned. If we do get a form back check that the hidden
|
|
|
|
value is correctly managing the state of the form.
|
|
|
|
|
|
|
|
"""
|
|
|
|
# Pass strings for form submittal and add stage variable to
|
|
|
|
# show we previously saw first stage of the form.
|
2008-08-27 04:19:12 +08:00
|
|
|
self.test_data.update({'stage': 1})
|
|
|
|
response = self.client.post('/test1/', self.test_data)
|
2007-11-30 00:32:23 +08:00
|
|
|
# Check to confirm stage is set to 2 in output form.
|
|
|
|
stage = self.input % 2
|
|
|
|
self.assertContains(response, stage, 1)
|
|
|
|
|
|
|
|
def test_form_submit(self):
|
|
|
|
"""
|
|
|
|
Test contrib.formtools.preview form submittal.
|
|
|
|
|
|
|
|
Use the client library to POST to the form with stage set to 3
|
|
|
|
to see if our forms done() method is called. Check first
|
|
|
|
without the security hash, verify failure, retry with security
|
|
|
|
hash and verify sucess.
|
|
|
|
|
|
|
|
"""
|
|
|
|
# Pass strings for form submittal and add stage variable to
|
|
|
|
# show we previously saw first stage of the form.
|
2008-08-27 04:19:12 +08:00
|
|
|
self.test_data.update({'stage':2})
|
|
|
|
response = self.client.post('/test1/', self.test_data)
|
2010-12-04 15:28:12 +08:00
|
|
|
self.assertNotEqual(response.content, success_string)
|
2008-08-27 04:19:12 +08:00
|
|
|
hash = self.preview.security_hash(None, TestForm(self.test_data))
|
|
|
|
self.test_data.update({'hash': hash})
|
|
|
|
response = self.client.post('/test1/', self.test_data)
|
|
|
|
self.assertEqual(response.content, success_string)
|
|
|
|
|
|
|
|
def test_bool_submit(self):
|
|
|
|
"""
|
|
|
|
Test contrib.formtools.preview form submittal when form contains:
|
|
|
|
BooleanField(required=False)
|
|
|
|
|
|
|
|
Ticket: #6209 - When an unchecked BooleanField is previewed, the preview
|
|
|
|
form's hash would be computed with no value for ``bool1``. However, when
|
|
|
|
the preview form is rendered, the unchecked hidden BooleanField would be
|
|
|
|
rendered with the string value 'False'. So when the preview form is
|
|
|
|
resubmitted, the hash would be computed with the value 'False' for
|
|
|
|
``bool1``. We need to make sure the hashes are the same in both cases.
|
|
|
|
|
|
|
|
"""
|
|
|
|
self.test_data.update({'stage':2})
|
|
|
|
hash = self.preview.security_hash(None, TestForm(self.test_data))
|
|
|
|
self.test_data.update({'hash':hash, 'bool1':u'False'})
|
|
|
|
response = self.client.post('/test1/', self.test_data)
|
2007-11-30 00:32:23 +08:00
|
|
|
self.assertEqual(response.content, success_string)
|
|
|
|
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
def test_form_submit_django12_hash(self):
|
|
|
|
"""
|
|
|
|
Test contrib.formtools.preview form submittal, using the hash function
|
|
|
|
used in Django 1.2
|
|
|
|
"""
|
|
|
|
# Pass strings for form submittal and add stage variable to
|
|
|
|
# show we previously saw first stage of the form.
|
|
|
|
self.test_data.update({'stage':2})
|
|
|
|
response = self.client.post('/test1/', self.test_data)
|
2010-12-04 15:28:12 +08:00
|
|
|
self.assertNotEqual(response.content, success_string)
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
hash = utils.security_hash(None, TestForm(self.test_data))
|
|
|
|
self.test_data.update({'hash': hash})
|
|
|
|
response = self.client.post('/test1/', self.test_data)
|
|
|
|
self.assertEqual(response.content, success_string)
|
|
|
|
|
|
|
|
|
|
|
|
def test_form_submit_django12_hash_custom_hash(self):
|
|
|
|
"""
|
|
|
|
Test contrib.formtools.preview form submittal, using the hash function
|
|
|
|
used in Django 1.2 and a custom security_hash method.
|
|
|
|
"""
|
|
|
|
# Pass strings for form submittal and add stage variable to
|
|
|
|
# show we previously saw first stage of the form.
|
|
|
|
self.test_data.update({'stage':2})
|
|
|
|
response = self.client.post('/test2/', self.test_data)
|
|
|
|
self.assertEqual(response.status_code, 200)
|
2010-12-04 15:28:12 +08:00
|
|
|
self.assertNotEqual(response.content, success_string)
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
hash = utils.security_hash(None, TestForm(self.test_data))
|
|
|
|
self.test_data.update({'hash': hash})
|
|
|
|
response = self.client.post('/test2/', self.test_data)
|
2010-12-04 15:28:12 +08:00
|
|
|
self.assertNotEqual(response.content, success_string)
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
|
|
|
|
|
2009-05-13 05:54:58 +08:00
|
|
|
class SecurityHashTests(unittest.TestCase):
|
|
|
|
|
|
|
|
def test_textfield_hash(self):
|
|
|
|
"""
|
|
|
|
Regression test for #10034: the hash generation function should ignore
|
|
|
|
leading/trailing whitespace so as to be friendly to broken browsers that
|
|
|
|
submit it (usually in textareas).
|
|
|
|
"""
|
2009-05-13 06:02:38 +08:00
|
|
|
f1 = HashTestForm({'name': 'joe', 'bio': 'Nothing notable.'})
|
|
|
|
f2 = HashTestForm({'name': ' joe', 'bio': 'Nothing notable. '})
|
|
|
|
hash1 = utils.security_hash(None, f1)
|
|
|
|
hash2 = utils.security_hash(None, f2)
|
|
|
|
self.assertEqual(hash1, hash2)
|
2010-10-11 20:55:17 +08:00
|
|
|
|
2009-05-13 06:02:38 +08:00
|
|
|
def test_empty_permitted(self):
|
|
|
|
"""
|
|
|
|
Regression test for #10643: the security hash should allow forms with
|
|
|
|
empty_permitted = True, or forms where data has not changed.
|
|
|
|
"""
|
|
|
|
f1 = HashTestBlankForm({})
|
|
|
|
f2 = HashTestForm({}, empty_permitted=True)
|
2009-05-13 05:54:58 +08:00
|
|
|
hash1 = utils.security_hash(None, f1)
|
|
|
|
hash2 = utils.security_hash(None, f2)
|
|
|
|
self.assertEqual(hash1, hash2)
|
|
|
|
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
|
|
|
|
class FormHmacTests(unittest.TestCase):
|
|
|
|
"""
|
|
|
|
Same as SecurityHashTests, but with form_hmac
|
|
|
|
"""
|
|
|
|
|
|
|
|
def test_textfield_hash(self):
|
|
|
|
"""
|
|
|
|
Regression test for #10034: the hash generation function should ignore
|
|
|
|
leading/trailing whitespace so as to be friendly to broken browsers that
|
|
|
|
submit it (usually in textareas).
|
|
|
|
"""
|
|
|
|
f1 = HashTestForm({'name': 'joe', 'bio': 'Nothing notable.'})
|
|
|
|
f2 = HashTestForm({'name': ' joe', 'bio': 'Nothing notable. '})
|
|
|
|
hash1 = utils.form_hmac(f1)
|
|
|
|
hash2 = utils.form_hmac(f2)
|
|
|
|
self.assertEqual(hash1, hash2)
|
|
|
|
|
|
|
|
def test_empty_permitted(self):
|
|
|
|
"""
|
|
|
|
Regression test for #10643: the security hash should allow forms with
|
|
|
|
empty_permitted = True, or forms where data has not changed.
|
|
|
|
"""
|
|
|
|
f1 = HashTestBlankForm({})
|
|
|
|
f2 = HashTestForm({}, empty_permitted=True)
|
|
|
|
hash1 = utils.form_hmac(f1)
|
|
|
|
hash2 = utils.form_hmac(f2)
|
|
|
|
self.assertEqual(hash1, hash2)
|
|
|
|
|
|
|
|
|
2009-05-13 06:02:38 +08:00
|
|
|
class HashTestForm(forms.Form):
|
|
|
|
name = forms.CharField()
|
|
|
|
bio = forms.CharField()
|
|
|
|
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
|
2009-05-13 06:02:38 +08:00
|
|
|
class HashTestBlankForm(forms.Form):
|
|
|
|
name = forms.CharField(required=False)
|
|
|
|
bio = forms.CharField(required=False)
|
|
|
|
|
2008-08-27 05:33:56 +08:00
|
|
|
#
|
|
|
|
# FormWizard tests
|
|
|
|
#
|
|
|
|
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
|
2008-08-27 05:33:56 +08:00
|
|
|
class WizardPageOneForm(forms.Form):
|
|
|
|
field = forms.CharField()
|
|
|
|
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
|
2008-08-27 05:33:56 +08:00
|
|
|
class WizardPageTwoForm(forms.Form):
|
|
|
|
field = forms.CharField()
|
|
|
|
|
2011-01-14 05:58:11 +08:00
|
|
|
class WizardPageTwoAlternativeForm(forms.Form):
|
|
|
|
field = forms.CharField()
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
|
|
|
|
class WizardPageThreeForm(forms.Form):
|
|
|
|
field = forms.CharField()
|
|
|
|
|
|
|
|
|
2008-08-27 05:33:56 +08:00
|
|
|
class WizardClass(wizard.FormWizard):
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
|
|
|
|
def get_template(self, step):
|
|
|
|
return 'formwizard/wizard.html'
|
2008-08-27 05:33:56 +08:00
|
|
|
|
|
|
|
def done(self, request, cleaned_data):
|
|
|
|
return http.HttpResponse(success_string)
|
|
|
|
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
|
|
|
|
class UserSecuredWizardClass(WizardClass):
|
|
|
|
"""
|
|
|
|
Wizard with a custum security_hash method
|
|
|
|
"""
|
|
|
|
def security_hash(self, request, form):
|
|
|
|
return "123"
|
|
|
|
|
|
|
|
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-27 07:23:07 +08:00
|
|
|
class DummyRequest(http.HttpRequest):
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
|
2008-08-27 05:33:56 +08:00
|
|
|
def __init__(self, POST=None):
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-27 07:23:07 +08:00
|
|
|
super(DummyRequest, self).__init__()
|
2008-08-27 05:33:56 +08:00
|
|
|
self.method = POST and "POST" or "GET"
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-27 07:23:07 +08:00
|
|
|
if POST is not None:
|
|
|
|
self.POST.update(POST)
|
|
|
|
self._dont_enforce_csrf_checks = True
|
2008-08-27 05:33:56 +08:00
|
|
|
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
|
2008-08-27 05:33:56 +08:00
|
|
|
class WizardTests(TestCase):
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
urls = 'django.contrib.formtools.tests.urls'
|
|
|
|
|
|
|
|
def setUp(self):
|
|
|
|
self.old_TEMPLATE_DIRS = settings.TEMPLATE_DIRS
|
|
|
|
settings.TEMPLATE_DIRS = (
|
|
|
|
os.path.join(
|
|
|
|
os.path.dirname(__file__),
|
|
|
|
'templates'
|
|
|
|
),
|
|
|
|
)
|
|
|
|
# Use a known SECRET_KEY to make security_hash tests deterministic
|
|
|
|
self.old_SECRET_KEY = settings.SECRET_KEY
|
|
|
|
settings.SECRET_KEY = "123"
|
|
|
|
|
|
|
|
def tearDown(self):
|
|
|
|
settings.TEMPLATE_DIRS = self.old_TEMPLATE_DIRS
|
|
|
|
settings.SECRET_KEY = self.old_SECRET_KEY
|
|
|
|
|
2008-08-27 05:33:56 +08:00
|
|
|
def test_step_starts_at_zero(self):
|
|
|
|
"""
|
|
|
|
step should be zero for the first form
|
|
|
|
"""
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
response = self.client.get('/wizard/')
|
|
|
|
self.assertEquals(0, response.context['step0'])
|
2008-08-27 05:33:56 +08:00
|
|
|
|
|
|
|
def test_step_increments(self):
|
|
|
|
"""
|
|
|
|
step should be incremented when we go to the next page
|
|
|
|
"""
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
response = self.client.post('/wizard/', {"0-field":"test", "wizard_step":"0"})
|
|
|
|
self.assertEquals(1, response.context['step0'])
|
2008-08-27 05:33:56 +08:00
|
|
|
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
def test_bad_hash(self):
|
|
|
|
"""
|
|
|
|
Form should not advance if the hash is missing or bad
|
|
|
|
"""
|
|
|
|
response = self.client.post('/wizard/',
|
|
|
|
{"0-field":"test",
|
|
|
|
"1-field":"test2",
|
|
|
|
"wizard_step": "1"})
|
|
|
|
self.assertEquals(0, response.context['step0'])
|
|
|
|
|
|
|
|
def test_good_hash_django12(self):
|
|
|
|
"""
|
|
|
|
Form should advance if the hash is present and good, as calculated using
|
|
|
|
django 1.2 method.
|
|
|
|
"""
|
|
|
|
# We are hard-coding a hash value here, but that is OK, since we want to
|
|
|
|
# ensure that we don't accidentally change the algorithm.
|
|
|
|
data = {"0-field": "test",
|
|
|
|
"1-field": "test2",
|
|
|
|
"hash_0": "2fdbefd4c0cad51509478fbacddf8b13",
|
|
|
|
"wizard_step": "1"}
|
|
|
|
response = self.client.post('/wizard/', data)
|
|
|
|
self.assertEquals(2, response.context['step0'])
|
|
|
|
|
|
|
|
def test_good_hash_django12_subclass(self):
|
|
|
|
"""
|
|
|
|
The Django 1.2 method of calulating hashes should *not* be used as a
|
|
|
|
fallback if the FormWizard subclass has provided their own method
|
|
|
|
of calculating a hash.
|
|
|
|
"""
|
|
|
|
# We are hard-coding a hash value here, but that is OK, since we want to
|
|
|
|
# ensure that we don't accidentally change the algorithm.
|
|
|
|
data = {"0-field": "test",
|
|
|
|
"1-field": "test2",
|
|
|
|
"hash_0": "2fdbefd4c0cad51509478fbacddf8b13",
|
|
|
|
"wizard_step": "1"}
|
|
|
|
response = self.client.post('/wizard2/', data)
|
|
|
|
self.assertEquals(0, response.context['step0'])
|
|
|
|
|
|
|
|
def test_good_hash_current(self):
|
|
|
|
"""
|
|
|
|
Form should advance if the hash is present and good, as calculated using
|
|
|
|
current method.
|
|
|
|
"""
|
|
|
|
data = {"0-field": "test",
|
|
|
|
"1-field": "test2",
|
|
|
|
"hash_0": "7e9cea465f6a10a6fb47fcea65cb9a76350c9a5c",
|
|
|
|
"wizard_step": "1"}
|
|
|
|
response = self.client.post('/wizard/', data)
|
|
|
|
self.assertEquals(2, response.context['step0'])
|
2010-10-20 04:45:40 +08:00
|
|
|
|
|
|
|
def test_14498(self):
|
|
|
|
"""
|
2011-01-14 05:58:11 +08:00
|
|
|
Regression test for ticket #14498. All previous steps' forms should be
|
|
|
|
validated.
|
2010-10-20 04:45:40 +08:00
|
|
|
"""
|
2011-01-14 07:18:54 +08:00
|
|
|
reached = [False]
|
2010-10-20 04:45:40 +08:00
|
|
|
that = self
|
|
|
|
|
|
|
|
class WizardWithProcessStep(WizardClass):
|
|
|
|
def process_step(self, request, form, step):
|
|
|
|
that.assertTrue(hasattr(form, 'cleaned_data'))
|
2011-01-14 07:18:54 +08:00
|
|
|
reached[0] = True
|
2010-10-20 04:45:40 +08:00
|
|
|
|
|
|
|
wizard = WizardWithProcessStep([WizardPageOneForm,
|
|
|
|
WizardPageTwoForm,
|
|
|
|
WizardPageThreeForm])
|
|
|
|
data = {"0-field": "test",
|
|
|
|
"1-field": "test2",
|
|
|
|
"hash_0": "7e9cea465f6a10a6fb47fcea65cb9a76350c9a5c",
|
|
|
|
"wizard_step": "1"}
|
|
|
|
wizard(DummyRequest(POST=data))
|
2011-01-14 07:18:54 +08:00
|
|
|
self.assertTrue(reached[0])
|
2010-10-20 04:45:40 +08:00
|
|
|
|
2010-11-16 22:37:00 +08:00
|
|
|
def test_14576(self):
|
|
|
|
"""
|
|
|
|
Regression test for ticket #14576.
|
|
|
|
|
|
|
|
The form of the last step is not passed to the done method.
|
|
|
|
"""
|
|
|
|
reached = [False]
|
|
|
|
that = self
|
|
|
|
|
|
|
|
class Wizard(WizardClass):
|
|
|
|
def done(self, request, form_list):
|
|
|
|
reached[0] = True
|
|
|
|
that.assertTrue(len(form_list) == 2)
|
|
|
|
|
|
|
|
wizard = Wizard([WizardPageOneForm,
|
|
|
|
WizardPageTwoForm])
|
|
|
|
|
|
|
|
data = {"0-field": "test",
|
|
|
|
"1-field": "test2",
|
|
|
|
"hash_0": "2fdbefd4c0cad51509478fbacddf8b13",
|
|
|
|
"wizard_step": "1"}
|
|
|
|
wizard(DummyRequest(POST=data))
|
|
|
|
self.assertTrue(reached[0])
|
2011-01-14 05:58:11 +08:00
|
|
|
|
|
|
|
def test_15075(self):
|
|
|
|
"""
|
|
|
|
Regression test for ticket #15075. Allow modifying wizard's form_list
|
|
|
|
in process_step.
|
|
|
|
"""
|
2011-01-14 07:18:54 +08:00
|
|
|
reached = [False]
|
2011-01-14 05:58:11 +08:00
|
|
|
that = self
|
|
|
|
|
|
|
|
class WizardWithProcessStep(WizardClass):
|
|
|
|
def process_step(self, request, form, step):
|
|
|
|
if step == 0:
|
|
|
|
self.form_list[1] = WizardPageTwoAlternativeForm
|
|
|
|
if step == 1:
|
|
|
|
that.assertTrue(isinstance(form, WizardPageTwoAlternativeForm))
|
2011-01-14 07:18:54 +08:00
|
|
|
reached[0] = True
|
2011-01-14 05:58:11 +08:00
|
|
|
|
|
|
|
wizard = WizardWithProcessStep([WizardPageOneForm,
|
|
|
|
WizardPageTwoForm,
|
|
|
|
WizardPageThreeForm])
|
|
|
|
data = {"0-field": "test",
|
|
|
|
"1-field": "test2",
|
|
|
|
"hash_0": "7e9cea465f6a10a6fb47fcea65cb9a76350c9a5c",
|
|
|
|
"wizard_step": "1"}
|
|
|
|
wizard(DummyRequest(POST=data))
|
2011-01-14 07:18:54 +08:00
|
|
|
self.assertTrue(reached[0])
|