Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Better description in the release notes of what's going on with the P…

…asswordInput change.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@14541 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
commit dc0accb5a30722edffd6b4a4930298041f6d9d5b 1 parent b951ffb
@ubernostrum ubernostrum authored
Showing with 31 additions and 36 deletions.
  1. +16 −18 docs/releases/1.3-alpha-1.txt
  2. +15 −18 docs/releases/1.3.txt
View
34 docs/releases/1.3-alpha-1.txt
@@ -169,29 +169,27 @@ Backwards-incompatible changes in 1.3 alpha 1
PasswordInput default rendering behavior
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Prior to Django 1.3, a :class:`~django.forms.PasswordInput` would render
-data values like any other form. If a form submission raised an error,
-the password that was submitted would be reflected to the client as form
-data populating the form for resubmission.
-
-This had the potential to leak passwords, as any failed password
-attempt would cause the password that was typed to be sent back to the
-client.
-
-In Django 1.3, the default behavior of
-:class:`~django.forms.PasswordInput` is to suppress the display of
-password values. This change doesn't alter the way form data is
-validated or handled. It only affects the user experience with
-passwords on a form when they make an error submitting form data (such
-as on unsuccessful logins, or when completing a registration form).
-
-If you want restore the pre-Django 1.3 behavior, you need to pass in a
-custom widget to your form that sets the ``render_value`` argument::
+The :class:`~django.forms.PasswordInput` form widget, intended for use
+with form fields which represent passwords, accepts a boolean keyword
+argument ``render_value`` indicating whether to send its data back to
+the browser when displaying a submitted form with errors. Prior to
+Django 1.3, this argument defaulted to ``True``, meaning that the
+submitted password would be sent back to the browser as part of the
+form. Developers who wished to add a bit of additional security by
+excluding that value from the redisplayed form could instantiate a
+:class:`~django.forms.PasswordInput` passing ``render_value=False`` .
+
+Due to the sensitive nature of passwords, however, Django 1.3 takes
+this step automatically; the default value of ``render_value`` is now
+``False``, and developers who want the password value returned to the
+browser on a submission with errors (the previous behavior) must now
+explicitly indicate this. For ezmple::
class LoginForm(forms.Form):
username = forms.CharField(max_length=100)
password = forms.CharField(widget=forms.PasswordInput(render_value=True))
+
Clearable default widget for FileField
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
View
33 docs/releases/1.3.txt
@@ -160,24 +160,21 @@ Backwards-incompatible changes in 1.3
PasswordInput default rendering behavior
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Prior to Django 1.3, a :class:`~django.forms.PasswordInput` would render
-data values like any other form. If a form submission raised an error,
-the password that was submitted would be reflected to the client as form
-data populating the form for resubmission.
-
-This had the potential to leak passwords, as any failed password
-attempt would cause the password that was typed to be sent back to the
-client.
-
-In Django 1.3, the default behavior of
-:class:`~django.forms.PasswordInput` is to suppress the display of
-password values. This change doesn't alter the way form data is
-validated or handled. It only affects the user experience with
-passwords on a form when they make an error submitting form data (such
-as on unsuccessful logins, or when completing a registration form).
-
-If you want restore the pre-Django 1.3 behavior, you need to pass in a
-custom widget to your form that sets the ``render_value`` argument::
+The :class:`~django.forms.PasswordInput` form widget, intended for use
+with form fields which represent passwords, accepts a boolean keyword
+argument ``render_value`` indicating whether to send its data back to
+the browser when displaying a submitted form with errors. Prior to
+Django 1.3, this argument defaulted to ``True``, meaning that the
+submitted password would be sent back to the browser as part of the
+form. Developers who wished to add a bit of additional security by
+excluding that value from the redisplayed form could instantiate a
+:class:`~django.forms.PasswordInput` passing ``render_value=False`` .
+
+Due to the sensitive nature of passwords, however, Django 1.3 takes
+this step automatically; the default value of ``render_value`` is now
+``False``, and developers who want the password value returned to the
+browser on a submission with errors (the previous behavior) must now
+explicitly indicate this. For ezmple::
class LoginForm(forms.Form):
username = forms.CharField(max_length=100)
Please sign in to comment.
Something went wrong with that request. Please try again.