Basie Blog

A Lightweight Software Development Portal in Django

User Registration

with 8 comments

Currently Basie is with out any kind of user registration system and all new users have to be added by an existing super user. Creating such a system would not be overly complicated but why reinvent the wheel when there are existing open source apps for django that can be dropped in?

django-registration

Site
: http://bitbucket.org/ubernostrum/django-registration/

License: New BSD License

Requires: Django 1.0 or newer

django-registartion is by far the most talked about and recommended of the registration systems i looked in to (it is used by djangoproject.com) with multiple blogs recommending it and describing it’s use. It provides a simple sing up processes where a user sings up for an account, is sent an activation e-mail and then may activate there account with the link sent in the e-mail.

The application is small, simple and too the point and has no other dependencies but django and is currently on it’s v0.7th release. The down side is that it has no support for systems like open id and the default install method seem to want to install the application system wide rather then just a drop in application.

django-openid

Site: http://code.google.com/p/django-openid/

License: New BSD License

Requires
: python-openid library, session support.

django-openid makes authentication use OpenID and as such pushes the user registration work on to the OpenID system. The down side of this is it does not support normal password/username authentication and registration, as well as require a bit of custom code to be done to get running.

django-authopenid

Site: http://code.google.com/p/django-authopenid/

License: New BSD License

Requires: python-openid 2.x, python-elementreee, httplib2

django-authopenid allows for authentication by both OpenID and the normal username/password method. It also allows for a user to bind an OpenID account to there existing username/password account to provide backwards capability.

The downside is there is no e-mail activation and it has not been as thoroughly tested and polished as django-registration (or as widely used in the django community).


Sources: http://lethain.com/entry/2008/oct/25/user-registration-apps-for-django/, http://bitbucket.org/ubernostrum/django-registration/wiki/Home, http://code.google.com/p/django-openid/, http://code.google.com/p/django-authopenid/

Written by Dan

January 20th, 2009 at 7:44 pm

8 Responses to 'User Registration'

Subscribe to comments with RSS or TrackBack to 'User Registration'.

  1. IMHO, django-registration is the only way to go — we don't want to go with something immature (django-authopenid) and we don't want to rely on users having an OpenID (django-openid) (that would mean we would also have to become an OpenID provider, which would mean we would need to support registration, which sets us back to step 0).

    David Wolever

    21 Jan 09 at 9:47 am

  2. Is there any current (or planned) path to migrate a system from django-registration to django-authopenid? If so, then django-registration sounds like a natural first step to take.

    I don't enjoy the process of having to sign up for every new site I encounter, and OpenID is a solution to that problem. I think this comes down to the use-case as well though – will Basie be used only for course projects and maintained for a classroom setting? Or will it be general purpose and used by arbitrarily group project development? If the latter, then I would not recommend ruling out OpenID.

    Haz

    21 Jan 09 at 12:04 pm

  3. I think that the world is moving toward an easy/fast registration process, that will bother the user as less as possible, but I'm still not sure that I'm ready to let go on the email verification system…
    The best strategy for us will probably be:
    1. install the solid django-registration app, as it is widely used and trusted.
    2. Plug in the django-openid app and introduce the modification needed in order to work side-by-side with the previous one.
    If both will work fine together, I think that the cost of letting go on the regular registration feature is bearable.

    Henig

    22 Jan 09 at 5:17 am

  4. If we did start with django-registration and some day want to switch to django-authopenid i don't think it would be much of a problem as django-authopenid is backwards combatable witch normal (password/username) accounts.

    dservos

    22 Jan 09 at 8:49 pm

  5. django-authopenid is already about what you would get if you combined the too, minus the email verification. I think it would be easier to add email verification to django-authopenid then combined django-registration and django-openid.

    dservos

    22 Jan 09 at 9:01 pm

  6. User self-registration with approval is a must-have for widely-deployed systems, but for systems at schools, we must also support integration with whatever auth system the school has in place already. DrProject's handling of this is pretty complicated: UID/password is passed to a C program that checks (a) a handwritten password file, (b) the host password file, and (c) a concatenation of partial password files imported from the department's undergrad lab machines. (Even here, I'm simplifying — the reality is more complicated.) What we *really* need is pluggable, chained authentication, so that we can tell the system to do the following in some order:

    * check credentials stored inside the Basie database
    * check OpenID credentials
    * check Kerberos (for those who use it)
    * check one or more Unix password files (for those who use it)
    * check LDAP (for those who use it)

    etc. This is *not* in scope for 0.2, so yeah, something that gives us username/password authentication with credentials stored inside Basie, self-registration with approval, and nothing else would be very welcome.

    Greg Wilson

    23 Jan 09 at 10:27 am

  7. Until now Basie's authentication relies on a3c app. This app has two backends: ModelBackend and ExternalBackend.

    ModelBackend is very similar to the 'django.contrib.auth.backends.ModelBackend'. It only adds an extra layer that checks the user status (defined in a3c.models.UserProfile) with could be APPROVED, PENDING_APPROVAL or PENDING_CONFIRMATION. The user registration will have to be interconnected with the a3c app and it will have a close relationship with the ModelBackend and the UserProfile model. Probably both the a3c app and the django-registration (if you decide to use it) will have to change at least a little.

    ExternalBackend replaces the django's “user.check_password(password)” validation with another validation method that uses scripts and data files like in (or similar) DrProject.

    More info about backends on: http://docs.djangoproject.com/en/dev/topics/aut...

    zuzelvp

    23 Jan 09 at 11:53 am

  8. [...] is a pluggable Django app that implements a common registration-activation flow. This flow is quite similar to the password reset flow, but slightly simpler with only 3 [...]

Leave a Reply