django.contrib.auth: Confusion about AuthenticationForm.confirm_login_allowed

[Christian Franke]

Hello,

I am a bit confused about the relation and separation of
responsibilities between `AuthenticationForm.confirm_login_allowed` and
`ModelBackend.user_can_authenticate`.

When `AuthenticationForm` is used together with `ModelBackend`, we will
never call `AuthenticationForm.confirm_login_allowed` for an inactive
account, because `ModelBackend.authenticate` will never return an
inactive user, as `ModelBackend.user_can_authenticate` will return
`False` for inactive users. So the error message "This account is
inactive." is never shown for this combination of Form and Backend, and
the error message will always be about an incorrect password.

When `AuthenticationForm` is combined with `AllowAllUsersModelBackend`,
`AuthenticationForm.confirm_login_allowed` will be called and raise a
validation error for inactive accounts, because they are returned from
the backend, leading to the error message "This account is inactive."

Given that `AuthenticationForm.confirm_login_allowed` exists the way
that it does, it seems like there are valid configurations in which the
form has the responsibility to determine the user's authorization to log in.

However, it seems quite dangerous to me to leave it up to the form to
deny login to users, e.g. because there might be other ways of
authentication that are not using AuthenticationForm.

So my question would be: Under which circumstances is it a good idea to
leave such authorization decisions up to the form/what setup did the
original authors have in mind when writing `confirm_login_allowed`?

All Best,
Chris

--
I like PGP. How about:
curl -slf https://nowhere.ws/nowhere.asc | gpg --import -