Why is Admin login template at admin/login.html instead of registration/login.html?

[Carsten Fuchs]

Dear Django fellows,

using Django 1.8.3, I see that the Admin contrib uses the Auth contrib's views (in
contrib/admin/sites.py). The implementation overrides the auth views' defaults only if
explicitly specified in the AdminSite object.

For example, changing the user password is implemented in
contrib.admin.sites.password_change() via django.contrib.auth.views.password_change
which in turn by default uses template "registration/password_change_form.html", for
which the Admin contrib brings a matching file.

Only for the login, which is implemented in contrib.admin.sites.login() via
django.contrib.auth.views.login and which by default uses "registration/login.html",
does the Admin give a different value, namely "admin/login.html" (if there was no
explicit user override in the AdminSite object).

Why is the login in this regard an exception?

It seems simpler and more natural to me if the Admin used registration/login.html for
logins as well.


And a related follow-up question:
Why does the Admin contrib duplicate the Auth views and URLs in the first place?

E.g. when the Admin is installed, there is URL "admin/login/", but as soon as we use our
own login at settings.LOGIN_URL, there are two login pages (with different templates,
see above) that serve the exact same purpose.

It seems like this makes it a bit easier getting started with the Admin, but I think
it's pretty confusing later. Or am I missing / misunderstanding something?

Many thanks and best regards,
Carsten

[Tim Graham]

The admin login only allows staff users to login so it makes sense to me that if you wanted to add regular user login to your site, it should have separate URLs.

As for the template issue, it seems to me the admin/template/registration templates should be more like admin/login.html and namespaced under admin so that if you want to implement a non-admin password reset, you don't have a conflict in the template names (see the ticket below for an example).

https://code.djangoproject.com/ticket/20372

[Carl Meyer]

On 07/23/2015 10:49 AM, Tim Graham wrote:
> The admin login only allows staff users to login so it makes sense to me
> that if you wanted to add regular user login to your site, it should
> have separate URLs.
>
> As for the template issue, it seems to me the
> admin/template/registration templates should be more like
> admin/login.html and namespaced under admin so that if you want to
> implement a non-admin password reset, you don't have a conflict in the
> template names (see the ticket below for an example).
>
> https://code.djangoproject.com/ticket/20372

I agree. The auth views expose the option to pass a different template
name. I think the admin should have its own templates namespaced under
`admin/` and pass those template names to the views, rather than
overriding the default auth templates.

Carl

[Carsten Fuchs]

Hi Tim,

many thanks for your reply!

Am 23.07.2015 um 18:49 schrieb Tim Graham:
> The admin login only allows staff users to login so it makes sense to me that if you
> wanted to add regular user login to your site, it should have separate URLs.

I think what confuses me is the fact that (in the Auth app) there is only one User
model, and the only difference between regular and staff users is the User.is_staff flag.

For example, if a staff user logs out of the Admin, he is logged out as a regular user
as well. If a regular user logs in via a custom login page, then browses to an Admin
page, some kind of error report or redirect must occur.

Given this, authentication is like a user-centric, site-wide feature rather than an
app-specific one, isn't it?

> As for the template issue, it seems to me the admin/template/registration templates
> should be more like admin/login.html and namespaced under admin so that if you want to
> implement a non-admin password reset, you don't have a conflict in the template names
> (see the ticket below for an example).
>
> https://code.djangoproject.com/ticket/20372
>

Well, I am quite happy about the admin using the registration/... templates by default:
With the view that authentication is user- rather than app-specific, I recently made my
admin and regular logins look identical, which worked very well.
So ticket 20372 is quite the opposite of my view. ;-)

In fact, I'd even prefer if the admin came with no auth dependency at all. I'm aware
that that would make getting started harder (and easily getting started was one of the
things I was very grateful for while taking my first steps with Django!), but if the
admin and auth were explicitly separate, it would also remove all confusion both in the
spirit of ticket 20372 and the opposite of it.

Best regards,
Carsten

[Carl Meyer]

Hi Carsten,

On 07/23/2015 11:41 AM, Carsten Fuchs wrote:
> Am 23.07.2015 um 18:49 schrieb Tim Graham:
>> The admin login only allows staff users to login so it makes sense to
>> me that if you
>> wanted to add regular user login to your site, it should have separate
>> URLs.
>
> I think what confuses me is the fact that (in the Auth app) there is
> only one User model, and the only difference between regular and staff
> users is the User.is_staff flag.
>
> For example, if a staff user logs out of the Admin, he is logged out as
> a regular user as well. If a regular user logs in via a custom login
> page, then browses to an Admin page, some kind of error report or
> redirect must occur.
>
> Given this, authentication is like a user-centric, site-wide feature
> rather than an app-specific one, isn't it?

Sure, the logged-in status of a given session is site-wide. But that
doesn't imply that there must be only a single login page, that always
looks the same and behaves the same. Normally on a Django site (with the
defaults) you'd have an admin login page which only allows staff users
to log in, and redirects them by default to the admin post-login, and is
styled to look like the admin. And you'd have a public login page which
allows any user to login, and redirects them by default to somewhere
else (not the admin) post-login.

There's no contradiction between having two (or more!) such login pages,
and the fact that once a user logs in with either of those login pages,
they are logged in to the whole site.

Of course it's _possible_ to have just a single login page instead, if
you want that, but it's not at all clear to me that that's better. I
prefer to keep the admin relatively separate from the public site.

And I think the same is true for password-reset etc. I'd prefer to leave
the admin with its own pages, styled consistently with the rest of the
admin, and design my own pages for public users, consistent with the
design of the rest of the public site.

>> As for the template issue, it seems to me the
>> admin/template/registration templates
>> should be more like admin/login.html and namespaced under admin so
>> that if you want to
>> implement a non-admin password reset, you don't have a conflict in the
>> template names
>> (see the ticket below for an example).
>>
>> https://code.djangoproject.com/ticket/20372
>>
>
> Well, I am quite happy about the admin using the registration/...
> templates by default: With the view that authentication is user- rather
> than app-specific, I recently made my admin and regular logins look
> identical, which worked very well.
> So ticket 20372 is quite the opposite of my view. ;-)

Presuming we made the admin use its own templates for all of this, you
could achieve what you want by also overriding the admin templates and
just making them inherit everything from your templates. A tiny bit of
boilerplate, but not much.

I think the preferable default is to have the admin separate.

Carl

[Carsten Fuchs]

Hi Carl,

Am 23.07.2015 um 20:07 schrieb Carl Meyer:
> Of course it's _possible_ to have just a single login page instead, if
> you want that, but it's not at all clear to me that that's better. I
> prefer to keep the admin relatively separate from the public site.
>
> And I think the same is true for password-reset etc. I'd prefer to leave
> the admin with its own pages, styled consistently with the rest of the
> admin, and design my own pages for public users, consistent with the
> design of the rest of the public site.

Yes, I certainly see your point. If I could start all over with my first (and now major)
Django project, or in the mid-term future, I'd probably also do it like this.


Allow me to add some background info:

When I started with Django and worked through the tutorials, augmenting and building my
first project in the process, it was very nice to get quick success and highly useful
results with the Django Admin. Also the first custom view was quickly written thanks to
the forms and templates features.

But... while I understand HTML and CSS at a logical level, I'm a horrible web designer.
For my first view and its related template, I quasi had nothing; no basis that looked
anywhere near visually acceptable, especially none that came with a nice top navigation
bar, user links, etc. And so what did I do, against all advice and documentation? I used
the Admin templates as a basis for my custom views. (I hope than anyone will ever talk
to me again after this. ;-) )

Worse, soon I had a model that I wanted users to be able to deal with almost like
administrators: (View,) create, edit, and delete instances at will. The only difference
to "real" is_staff admins was a filtered/limited QuerySet. But with changelists that
support pagination, filtering, sorting and searching.

Really, until today I have no idea how I can achieve (i.e. duplicate) such functionality
in custom user views (without reinventing the wheel). (Maybe class-based views can do
that, I'm still with classic function-based views, and I really don't know if this makes
a difference.)

And so I got where I am now: Most of my regular users are also admin users, and they
don't even know the difference.

And so while I strive to get things properly separated again, I bridge the time by using
common designs at least for the custom and admin auth views. (Bootstrap is really
perfect for me, I wished I had it available from the very beginning. Would then never
have used the admin templates in custom views in the first place.)

> Presuming we made the admin use its own templates for all of this, you
> could achieve what you want by also overriding the admin templates and
> just making them inherit everything from your templates. A tiny bit of
> boilerplate, but not much.

Yes. Indeed, thanks to the AdminSite object, in an app's admin.py file, even a simple

admin.site.login_template = "registration/login.html"

is enough – this is the exact live code that I use now to override the
"admin/login.html" default.


Best regards,
Carsten