Authentication system : should I use contrib.auth or reinvent the wheel?

[Peyman]

Hi all,

I need an authentication system for my website; quite a common need
today, isn't it?
I have decided to figure out if I can use django.contrib.auth. I
have the following problems :

1. start a new project, and just do the minimum:
*in settings:
- a database
- a template path
- the django.contrib.admin app
*then syncdb
*in urls: uncomment the admin urls
*add in your template folder, the file requested by the view
password_change in contrib.auth.views :
- registration/password_change_form.html
- this file contains a simple text

Problem : trying to access http://<your.site>/admin/password_change
will render -- after login -- your template in registration/
password_change_form.html instead of the admin one. I can't find out
why.

2. strange things in code :
- in contrib.auth there is a UserCreationForm provided, but there
seems to be no view for it or for any signup page.
- in contrib.auth.views, the login sends no error for authentication
failures, and sends the page again silently.

I hope I am wrong in all this, due to the fact that I am a new django
user. Your help is welcome.
Also : instead of contrib.auth, what is generally used for
authenticating users?

Thanks
-- Peyman

[Peyman]

> - in contrib.auth.views, the login sends no error for authentication
> failures, and sends the page again silently.

My mistake: the form.errors contains the authentication error.

[Bjunix]

I would strongly suggest to go with contrib.auth as quite a lot in the
django universe revolves arround it.

Remember you can also write your own login/logout/... views but still
using contrib.auth's models, forms and other utils.

You may also want to have a look at django-registration:
http://bitbucket.org/ubernostrum/django-registration/

[Peyman]

Thank you for your reply.
After having a look at its code, it seems that django-registration
provides the signup feature, and uses contrib.auth for the rest.

I looked at the source code of the djangoproject.com site itself (for
me, should use the best practices), and what a surprise : django-
registration is the app used for registration.
So, I just do not know what to think : why the django developers do
not add the signup feature to contrib.auth? It is just a few lines of
code, since it would need the same toolkit required by password_reset
to generate and check a unique link sent to the user.

Perhaps this has already been discussed, or perhaps it is planed. (*)

-- Peyman

* : just wondering, do Django developers read these posts or it there
any other way to share with them?

[Peyman]

FYI : here is the code for doing the registration process, with
confirmation email.
http://peyman-django.blogspot.com/2010/03/full-easy-authentication-using.html

[Russell Keith-Magee]

On Sat, Mar 20, 2010 at 9:55 AM, Peyman <peyman...@gmail.com> wrote:
> Thank you for your reply.
> After having a look at its code, it seems that django-registration
> provides the signup feature, and uses contrib.auth for the rest.
>
> I looked at the source code of the djangoproject.com site itself (for
> me, should use the best practices), and what a surprise : django-
> registration is the app used for registration.
> So, I just do not know what to think : why the django developers do
> not add the signup feature to contrib.auth? It is just a few lines of
> code, since it would need the same toolkit required by password_reset
> to generate and check a unique link sent to the user.

Firstly, if we added anything, we wouldn't add registration to
contrib.auth. Authentication is completely separate to registration;
good reusable applications should do one thing, and do it well. There
is a reason django-registration is (and should remain) a separate
application to contrib.auth. Instead,the preferred approach would be
to add django-registration to contrib (making contrib.registration).

The reason we don't add django-registration to contrib is that it
doesn't need to be there.

To rephrase your question: rather than asking "Can we add
django-registration to django.contrib?", ask "What does the django
project gain by adding an external project to core/contrib?"

To my mind, in this case the answer is "absolutely nothing".

Django-registration is a well maintained project (specifically, it is
maintained by Django's own release manager). It is available under the
same license as Django itself. It's easy to install, and it's easy to
integrate into your project.

Secondly, registration is a task where there is more than one "right"
solution, depending on the requirements of any given site. We don't
want to send a message that "if you're not using django-registration,
you're doing it wrong".

Thirdly, the core team has no desire to see Django expand until it
consumes every useful Django-related project in the world. We like the
fact that we have a community of useful applications surrounding the
core project. This means we can keep the core to a tight minimum
feature set, which means it's easier to hit release deadlines (which
we already have difficulty meeting), and diversify responsibility for
other parts of the ecosystem. The bigger the project becomes, the more
bugs we have to deal with, and the harder it will become to get
releases out on time.

Lastly, there is also a slight political reason for not integrating
django-registration. django-registration is maintained by our release
manager, who is also the biggest community advocate for reusable
applications. As a project, django-registration is a great resource to
point to when we need to say "see, it doesn't need to be in the core
to be useful" simply because it meets all the requirements of a good
external application :-)

> Perhaps this has already been discussed, or perhaps it is planed. (*)

Not formally. It's probably been suggested a bunch of times informally.

> -- Peyman
>
> * : just wondering, do Django developers read these posts or it there
> any other way to share with them?

Yes - we do read the mailing lists. That doesn't mean we participate
in every discussion -- if we did this, we'd never get any work done on
the project itself.

Discussions on django-developers will generally get more attention
than discussions on django-users, but be warned - django-developers
isn't just "second tier support". If you bring a question to
django-developers, it needs to be in the form of a specific proposal
to improve django in some way.

For example, in this case, the question "Is there any reason we
couldn't (or shouldn't) add django-registration to django.contrib",
would have been a reasonable query for django-developers.

Yours
Russ Magee %-)