Hi @Neraste ,
thanks for a very detailed bug report.

I'm still unsure if that's an actual bug; I'm trying to understand your use case.

Does that mean that you want your users to be able to log in when they are still unverified? and after they log in, they could theoretically change their email to another one? that use case may not work as expected, as using different field from is_active for a verification is not yet explored well.

The current assumption was to use only verified user data (with some exceptions, like reset password) to avoid security issues. But it looks that we could loosen up that requirement, as register_email endpoint requires authentication anyway. Perhaps it should be an opt-in setting, and at some point it could become the default one after some time? Do you think this is the right way to go?

I could see from the tests that using a different field than is_active is not deeply explored for now. My initial reason to use a such a field was because the Django documentation considers it's not designed for that use:

This [field] doesn’t necessarily control whether or not the user can log in. Authentication backends aren’t required to check for the is_active flag but the default backend (ModelBackend) and the RemoteUserBackend do. You can use AllowAllUsersModelBackend or AllowAllUsersRemoteUserBackend if you want to allow inactive users to login.

This also means that a using the AllowAllUsers*Backends would allow un-validated users to log in.

I think using is_active blurs the line between "this user is active" (which doesn't automatically mean they can log in) and "this user is allowed to log in."

A superuser created with the createsuperuser command is automatically active and, with the default field, their email address is also automatically valid, even if no verification occurs. They can log in because they are active/their email is valid. But for me, a superuser should log in whatever their email is because they are superuser and they are active, not because their email is valid, automatically or not.

Using a custom field, the superuser has not their email address validated by default. Their ability to log in depends on the authentication backend, but they cannot change their email with this library, which sounds unexpected and is the reason of this issue.

On the other hand, using is_active is convenient when using this library, you don't have to create a new field in your user model, and you don't have to write a custom authentication backend neither. So I also understand this choice.

I know this is a very edgy case, as you don't create tons of superusers from the command line.

On my side, I considered a superuser without a valid email would be acceptable in my authentication backend, so I was surprised that my superuser couldn't change their email. I imagined that they could pass trough the email check, as implemented in the PR. Eventually, I solved the problem in my project by forbidding users with un-validated email address to change their email address on the front (only such superusers should fall in this case).