Hi,
There is a rather old defect
https://code.djangoproject.com/ticket/19394 relating to the topic in hand, i.e. the use of the django.contrib.auth forms as-is when the default User model has been overridden such that the username is not used. It was closed by adding a documentation update after some discussion where it was understood that an actual code fix might be rather tricky.
I've been playing a little with this, and observed that this small change to Django 2.0:
================
$ diff -U3 /usr/local/lib/python3.6/dist-packages/django/contrib/admin/templates/admin/login.html templates/registration/login.html
--- /usr/local/lib/python3.6/dist-packages/django/contrib/admin/templates/admin/login.html 2017-12-15 10:16:27.859911680 +0000
+++ templates/registration/login.html 2017-12-21 15:50:22.071558380 +0000
@@ -35,7 +35,7 @@
{% if user.is_authenticated %}
<p class="errornote">
{% blocktrans trimmed %}
- You are authenticated as {{ username }}, but are not authorized to
+ You are authenticated as {{ user }}, but are not authorized to
access this page. Would you like to login to a different account?
{% endblocktrans %}
</p>
================
seems enough to make things work for me. Without the fix, the template variable expands to the empty string; with the fix it expands to "
f...@bar.com" as I expect. I'm rather new to Django, but IIUC, the fix works by replacing the explicit dependence on "username" with the str() of "user" (which calls get_username() and so honours the setting of USERNAME_FIELD in the replacement User model). Unless I've missed some other corner case, this appears to me to be a complete fix for the issue.
Please consider applying the above patch.
If needed, I could reopen the old defect, or start a new one. Please advise if that is the preferred approach.
Thanks, Shaheed