Possible bug in django.contrib.auth.forms.UserChangeForm's password field's help_text setup

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

Possible bug in django.contrib.auth.forms.UserChangeForm's password field's help_text setup

Shaheed Haque-2
Hi,

In Django 2.0, the help_text for the password field of django.contrib.auth.forms.UserChangeForm looks like this:

help_text=_(
            "Raw passwords are not stored, so there is no way to see this "
            "user's password, but you can change the password using "
            "<a href=\"{}\">this form</a>."
        ),

where the curly brackets are dealt with i nthe __init__() like this:

        self.fields['password'].help_text = self.fields['password'].help_text.format('../password/')

As far as I can see, this works just fine when the form is used as-is when logging in to the admin site. However, the hardcoded path "../password/" breaks in other contexts. In such other places, I see that doing this resolves the issue that ../password does not point to the right place:

        from ... import reverse
        self.fields['password'].help_text = self.fields['password'].help_text.format(reverse('password_change'))

I have checked, and my /usr/local/lib/python3.6/dist-packages/django/contrib/auth/urls.py does use the name implied here, so as far as I can see, it ought to be a safe fix. However, I am not familiar enough with Django to be sure of that (or indeed if this use case constitutes a bug), so am posting here for advice before opening a defect. Please advise if a defect is warranted/desired.

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/bf198a95-8e63-4885-8988-b4bf02cc6a3d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug in django.contrib.auth.forms.UserChangeForm's password field's help_text setup

Claude Paroz
This looks like a reasonable improvement. Please open a ticket, and possibly a pull request. Thanks!

Claude

Le vendredi 22 décembre 2017 03:29:56 UTC+1, Shaheed Haque a écrit :
Hi,

In Django 2.0, the help_text for the password field of django.contrib.auth.forms.UserChangeForm looks like this:

help_text=_(
            "Raw passwords are not stored, so there is no way to see this "
            "user's password, but you can change the password using "
            "<a href=\"{}\">this form</a>."
        ),

where the curly brackets are dealt with i nthe __init__() like this:

        self.fields['password'].help_text = self.fields['password'].help_text.format('../password/')

As far as I can see, this works just fine when the form is used as-is when logging in to the admin site. However, the hardcoded path "../password/" breaks in other contexts. In such other places, I see that doing this resolves the issue that ../password does not point to the right place:

        from ... import reverse
        self.fields['password'].help_text = self.fields['password'].help_text.format(reverse('password_change'))

I have checked, and my /usr/local/lib/python3.6/dist-packages/django/contrib/auth/urls.py does use the name implied here, so as far as I can see, it ought to be a safe fix. However, I am not familiar enough with Django to be sure of that (or indeed if this use case constitutes a bug), so am posting here for advice before opening a defect. Please advise if a defect is warranted/desired.

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/997ff992-f173-4475-98b2-a5a695664784%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug in django.contrib.auth.forms.UserChangeForm's password field's help_text setup

Shaheed Haque-2
In reply to this post by Shaheed Haque-2

Never mind, I realised that I was confused. It turns out that the hardcoded ../password thingy relates to the addition of a matching path in django.contrib.auth.admin.UserAdmin get_urls().

On Friday, 22 December 2017 02:29:56 UTC, Shaheed Haque wrote:
Hi,

In Django 2.0, the help_text for the password field of django.contrib.auth.forms.UserChangeForm looks like this:

help_text=_(
            "Raw passwords are not stored, so there is no way to see this "
            "user's password, but you can change the password using "
            "<a href=\"{}\">this form</a>."
        ),

where the curly brackets are dealt with i nthe __init__() like this:

        self.fields['password'].help_text = self.fields['password'].help_text.format('../password/')

As far as I can see, this works just fine when the form is used as-is when logging in to the admin site. However, the hardcoded path "../password/" breaks in other contexts. In such other places, I see that doing this resolves the issue that ../password does not point to the right place:

        from ... import reverse
        self.fields['password'].help_text = self.fields['password'].help_text.format(reverse('password_change'))

I have checked, and my /usr/local/lib/python3.6/dist-packages/django/contrib/auth/urls.py does use the name implied here, so as far as I can see, it ought to be a safe fix. However, I am not familiar enough with Django to be sure of that (or indeed if this use case constitutes a bug), so am posting here for advice before opening a defect. Please advise if a defect is warranted/desired.

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/b2a96893-ab4f-4982-9fd0-faf9a20f9c22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.