Suggestion: add default "registration/login.html" to django.contrib.auth

[Ilya Kazakevich]

Hello,

When I use Django auth, I need to provide login.html myself. But Django encourages applications to have default templates which can be overwritten by user (via filesystem.Loader, for example). 

I suggest to provide default login.html with simple HTML form. User may always overwrite it.

[Tino de Bruijn]

Yeah, or default to admin/login.html. The admin ships with all necessary "registration" templates, but for some reason only the login.html is included in the admin directory.

--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9487d6c7-8ee2-4a64-aae6-9a05574c1464%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tim Graham]

The admin templates extend "admin/base_site.html" and rely on the presence of specific template blocks so I don't think it's appropriate for those dependencies to be added to contrib.auth. I'm curious to see what content you would propose for a default template. Typically I've seen login templates that extend from a project's base template so it inherits all the project specific styles, JavaScript, etc. I'm not sure a default template would actually be used much in practice.

[Ilya Kazakevich]

I do not think admin templates should used. But something very simple and dumb (that looks similar to browser HTTP auth window). Here is example: http://pastebin.com/nnX36RB6

Css should be moved to static files, of course, to make this template cleaner and slightly more customizable. 

Imagine I need to create working solution as fast as I can. I really do not care about good UI now, because I need only a prototype to show it to my customer. I will not spent time creating nice login page: I just simply copy/paste template from Django documentation. And login page from contrib is great aid here. I will probably change login page UI later, but it is minor issue and priority is low. Many people in Intranet solutions (portals, CRMs and so on) are happy with browser HTTP auth window. They really do not care about how ugly is it.

[Marc Tamlyn]

I can see the merit of including our documented example as an actual template as a starting point. It's unlikely to be used exactly as is very often but it reduces getting started friction for some users - "huh this view doesn't work, better go read the docs"

I'd perhaps be inclined to include it without styles even.

Marc

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/aae4454c-7823-41cc-aaf2-914eb7b7c95f%40googlegroups.com.

[Ilya Kazakevich]

I agree: adding template from example is good idea! And I believe it will be used at least by newbies who just study Django auth system and by people who just need prototype. Providing default is better than copy/pasting example from docs.

[Ilya Kazakevich]

So, should I create a ticket?

[Aymeric Augustin]

I agree: providing a default login template would help. Getting started with contrib apps should be as easy as possible.

However the current proposal is backwards incompatible for users who define the login template in one of their apps that comes before django.contrib.auth in INSTALLED_APPS (if I remember the priority order correctly).

I don't think that prevents us from making the change but it should be pointed out in the release notes.

A more backwards-compatible alternative is to ship a default_login.html template and use select_template to fallback to that template when login.html isn't found.

-- 

Aymeric.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1GiLB5igByW-F9JVpu0WicQ4G1nKsKYc-wjUenqE%3DG59w%40mail.gmail.com.

[Marc Tamlyn]

I believe we standardised priority order such that earlier in the list always takes priority. Historically we had different orders for different things (templates, template tags, static files etc).

In any case, I don't think this should be a blocker and I'm in favour of including it as `registration/login.html`.

Ilya - You can find everything you need here: https://docs.djangoproject.com/en/1.7/internals/contributing/new-contributors/

Marc

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/E6284B83-2B24-4A12-8EB6-F607CBE52C3A%40polytechnique.org.

[Aymeric Augustin]

You're correct, the first app has priority. Only management commands used to work the other way round. (Remind me who made that change?)

-- 

Aymeric.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1HC-qnToXtfDWojUTtHdi-gk9rpowD7SmLp%2BS-xaiu%2BjQ%40mail.gmail.com.

[Collin Anderson]

Could be as simple as: <form method="post">{% csrf_token %}{{ form }}<input type="submit" value="Login"></form>