PasswordResetView should work with AbstractBaseUser subclasses without is_active field.

[Brylie Christopher Oxley]

I have a user model that extends AbstractBaseUser. When trying to reset a user password via the django.contrib.auth.views.PasswordResetView, I get the following error:

FieldError at /accounts/password_reset/
Cannot resolve keyword 'is_active' into field.

While the AbstractBaseUser class does have an is_active property set to True, it seems that the PasswordResetView is somehow excluding this property.

The issue is resolved by adding an is_active BooleanField to my User model, but seems like a bug in PasswordResetView.

[Mariusz Felisiak]

This is a ​documented limitation:

"PasswordResetForm: Assumes that the user model has a field that stores the user’s email address with the name returned by get_email_field_name() (email by default) that can be used to identify the user and a boolean field named is_active to prevent password resets for inactive users."

[Brylie Christopher Oxley]

Thanks for pointing me to the docs Mariusz.

I still believe this is a bug for a couple of reasons. First, Django is inconsistent since the AbstractBaseUser can't be used in the standard password reset views, despite having the is_active boolean property. Likewise, the default Django password reset flow is not resilient to User models that don't have is_active defined as a field, even when the downstream project may not need an activation flow (or use the same model field/property).

I believe there could actually be a middle ground here if we could give this issue a bit more time for consideration, rather than immediately dismissing it as invalid. One solution could be to check for the existence of the is_active property/field and run the relevant checks only if the field/property has a value.

From what I understand, some contributor has likely added the is_active boolean property to the AbstractBaseUser model to harmonize it with other parts of the authentication framework. Conversely, the different parts of the authentication framework, namely the password reset flow, could be made more resilient to the absence of an is_active field/property.

[Mariusz Felisiak]

I still believe this is a bug for a couple of reasons.

Documented behavior cannot be called a bug (it's documented since f0425c72601f466c6a71518749c6d15b94945514). Password reset views/forms make various assumptions about the user model and all of them are documented.

As far as I'm aware you're proposing a new feature. You can always define your own subclass of PasswordResetForm and override the get_users() method.

As it's a long standing behavior in a security-related area, I'm closing this as "wontfix" with a request for a discussion on the mailing list, so please first start a discussion on the DevelopersMailingList, where you'll reach a wider audience and see what other think. Also, ​follow the guidelines with regards to requesting features. Thanks.