Forms in django.contrib.auth have "username" as a hardcoded field value (patch included)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Forms in django.contrib.auth have "username" as a hardcoded field value (patch included)

Shaheed Haque-2
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 "[hidden email]" 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

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b673da95-6161-436c-9dc9-2cad3c555020%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Forms in django.contrib.auth have "username" as a hardcoded field value (patch included)

Tim Graham-2
The change looks reasonable. Please open a ticket and if you wish to create a pull request, also add a test.

You may find the original commit that added that notice useful:
https://github.com/django/django/commit/635ffc3c37d58eb96ae17d5389dd50bf635413c6

On Thursday, December 21, 2017 at 9:29:56 PM UTC-5, Shaheed Haque wrote:
Hi,

There is a rather old defect <a href="https://code.djangoproject.com/ticket/19394" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F19394\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFRZLnapUHQOQzmcnEgOEgc7WUMGQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F19394\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFRZLnapUHQOQzmcnEgOEgc7WUMGQ&#39;;return true;">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 "<a href="javascript:" target="_blank" gdf-obfuscated-mailto="bvHH5BfdCwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">f...@..." 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

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4f65e558-59b8-4e85-ab9b-088303e737f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.