Opened 4 years ago

Closed 4 years ago

#31355 closed Cleanup/optimization (wontfix)

Improving auth app

Reported by: Dima Knivets Owned by: nobody
Component: contrib.auth Version: 3.0
Severity: Normal Keywords: auth prototyping
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Since one of the philosophies of Django is quick development, we need to do something about the auth app. At the moment, when a user starts a project that requires auth features they have to do these things manually:

  • build templates for each auth view (9 templates total)
  • build a SignUp view from scratch since it is not provided by Django, unlike other auth views
  • create a custom user model (this is recommended by Django docs and a user would likely want to be able to auth with email rather than username)

I've read that one of the reasons of not shipping the templates is that you can't provide a template that will fit on every site. But that reasoning is kind of missing the purpose. At a prototype stage, it doesn't matter much how your reset password template looks like. You just want the most basic functionality that works, so that you can focus on your custom features and come back to polishing the look later.

The problems that I described can easily consume from 2 to 10 hours of dev time (based on your familiarity with Django). These are the hours that could've been spent on the actual application.

One of the major use cases of high level frameworks like Django is prototyping. However, each element of friction, like the ones that I described, reduce the appeal of Django as a great tool for prototyping.

Change History (1)

comment:1 by Carlton Gibson, 4 years ago

Resolution: wontfix
Status: newclosed

It's a long-standing decision that this is out-of-scope for Django core. 10 minutes of search gives you many options for templates or registration views, and the view has been that these are better off as third-party options.

Changes in policy would require agreement on the DevelopersMailingList, but if you wish to raise it there please search the history first, as you would need to reference previous discussions and present arguments for (or against) the points that were raised before to show why there should be a change. (Without this it has no chance of progression.)

I hope that makes sense.

Note: See TracTickets for help on using tickets.
Back to Top