Allow customising the admin login URL

[benbacardi]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

Provide a hook to change/customise the admin login URL, to allow users to point it to custom login views such as an SSO redirect or similar.

Problem

We have many Django projects that are fronted by SSO. The LOGIN_URL setting is pointed to the social auth login view that issues the redirect to the SSO provider to initiate login. However, if the user first loads a Django Admin URL, the Django Admin login page is presented instead, ignoring the value of LOGIN_URL.

This is because it is hardcoded in get_urls of the AdminSite class: https://github.com/django/django/blob/6.0/django/contrib/admin/sites.py#L270

This cannot be overridden without either duplicating most of the get_urls function within your own AdminSite subclass, or defining a URL pattern that matches the path for admin:login but sits higher in the URL pattern hierarchy so hijacks requests for it. Both options seem like a hack.

Request or proposal

request

Additional Details

There is a good chance I am missing something obvious with how to override it in the current setup, or why it would be a bad idea to allow customisation anyway, so please do let me know if so!

Implementation Suggestions

Any mechanism for overriding the hardcoded admin:login URL could be adopted:

• a new setting for ADMIN_LOGIN_URL or similar
• extracting it to a property on AdminSite to make overriding it in a subclass easier
• etc

[github-actions]

Thank you benbacardi for sharing your idea! We have a lot of them so please be patient. You can see the current queue here.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[KenWhitesell]

defining a URL pattern that matches the path for admin:login but sits higher in the URL pattern hierarchy so hijacks requests for it.

This is not a "hack". See the docs for Naming URL patterns

Quoting directly from the docs:

You can deliberately choose the same URL name as another application if you want to override a view. For example, a common use case is to override the LoginView.

[benbacardi]

@KenWhitesell absolutely, but that's talking about django.contrib.auth.views.LoginView, which is designed as a basic implementation to be overridden. The Django Admin hardcodes a lookup to a URL called admin:login, which is namespaced within the admin namespace and feels much more hacky to override, IMO.

[KenWhitesell]

It's referencing the LoginView as a common use-case example, not as the definitive list of views / urls that you can do this with.

The point of that section in the docs is to identify that this is the way to override URLs and named patterns. It's not a "hack" - it's how it's intended to be done.

[benbacardi]

I get what you’re saying, but I still think this situation is different.

My login view is provided by a package; it already has a path and a name. I can’t rename it (and nor should I want my global login view named admin:login) so I’d have to duplicate the URL pattern with a new path just to give it a second name to be used by the admin instead.

The login view provided by django.contrib.auth isn’t mapped to a URL already; providing your own with a name of login makes sense to tell the auth framework “this is my login view”. You then have to duplicate it, as above, to also call it admin:login; this doesn’t feel right to me.

I think the core thing I’m trying to say here is that the admin doesn’t respect the LOGIN_URL as defined by settings. The auth framework does. I’m don’t think the admin should unilaterally respect that setting, but I’m suggesting a way of saying “this is my global login URL regardless of which INSTALLED_APP you happen to be” is of value. I don’t believe the admin should be special, nor should we have to duplicate URL patterns and provide admin-specific login paths.

[KenWhitesell]

I can’t rename it (and nor should I want my global login view named admin:login)

I don't see why not.

But that's not, strictly-speaking, necessary. If the url assigned to your login view is /admin/login, then it will be used by the admin. There's no need for duplicate entries.

You also have the ability to provide a custom login method by overriding the AdminSite.login method to reference your global login view.

So no, given at least three different ways to unify your login between auth and admin, I don't see where adding yet another setting to provide a fourth adds value.

[benbacardi]

I don't see why not.

a. I can't, because it's in a package
b. I shouldn't have to, because it's not "the admin login". It's the entire site's login.

If the url assigned to your login view is /admin/login, then it will be used by the admin. There's no need for duplicate entries

See above: I can't without duplication; it's in a package, with the URLs provided by that package.

Given the use of the SSO package we have (using EntraID as an example here):

[
  path("entra/", include("entra.urls")),
  path("admin/", admin.site.urls),
]

My options, as you've pointed out, are these:

Shadow the path. The Entra login page is now available twice, at /entra/<whatever-path-the-package-provides> and at /admin/login, and I've had to specifically point at the full path to the view inside the Entra package.

[
  path("entra/", include("entra.urls")),
  path("admin/login/", entra.views.social.EntraSSOLogin),
  path("admin/", admin.site.urls),
]

Shadow the view name. Same as above, but the path doesn't matter.

[
  path("entra/", include("entra.urls")),
  path("blah/whatever/eh/", entra.views.social.EntraSSOLogin, name="admin:login"),
  path("admin/", admin.site.urls),
]

Provide my own AdminSite which overrides the def login view, purely to redirect to the other view. A bit overkill, no?

None of these options are "nice" to me. They add pointless URL paths or force me to redefine the login view that I want to use for my Django project globally. I think there would be a much nicer way to do this.

Clearly you disagree; that's fine, but I think there may be more than just our two voices who have opinion here, and would rather any discussion isn't prematurely shut down 🙂