Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

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.