Effectively, the user creation form and the password change form use the
`UserAttributeSimilarityValidator` differently. It is possible to create a
user via a subclass of Django's `UserCreationForm` with a password that
would be denied by the password change form. This is because the user
creation form only checks similarity agains the `username` field. When
changing a password, the password is validated in similarity to
`username`, `first_name`, `last_name`, and `email`.
This seems highly undesirable.
The central cause is that the `ModelForm` superclass (of
`UserCreationForm`) hasn't yet created the `User` instance.
`UserCreationForm` manually adds `username` to the empty `User` instance
on line 105 to allow for user attribute validation. In the event a
developer subclasses `UserCreationForm`, then the form will still only
validate against the `username`, rather than all of the fields in the
field.
I will have a PR with a proposed fix (discussed in the mailing list)
shortly.
--
Ticket URL: <https://code.djangoproject.com/ticket/28127>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/28127#comment:1>
Comment (by jambonrose):
Opened PR: https://github.com/django/django/pull/8408
--
Ticket URL: <https://code.djangoproject.com/ticket/28127#comment:2>
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/28127#comment:2>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/28127#comment:3>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"a96b981d84367fd41b1df40adf3ac9ca71a741dd" a96b981d]:
{{{
#!CommitTicketReference repository=""
revision="a96b981d84367fd41b1df40adf3ac9ca71a741dd"
Fixed #28127 -- Allowed UserCreationForm's password validation to check
all user fields.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/28127#comment:4>