From dc0accb5a30722edffd6b4a4930298041f6d9d5b Mon Sep 17 00:00:00 2001 From: James Bennett Date: Fri, 12 Nov 2010 16:12:38 +0000 Subject: [PATCH] Better description in the release notes of what's going on with the PasswordInput change. git-svn-id: http://code.djangoproject.com/svn/django/trunk@14541 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/releases/1.3-alpha-1.txt | 32 +++++++++++++++----------------- docs/releases/1.3.txt | 31 ++++++++++++++----------------- 2 files changed, 29 insertions(+), 34 deletions(-) diff --git a/docs/releases/1.3-alpha-1.txt b/docs/releases/1.3-alpha-1.txt index 843dbd22670..f5d9610475f 100644 --- a/docs/releases/1.3-alpha-1.txt +++ b/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. +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`` . -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:: +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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/docs/releases/1.3.txt b/docs/releases/1.3.txt index 90aeaa8b838..a292205ed69 100644 --- a/docs/releases/1.3.txt +++ b/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. +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`` . -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:: +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)