On Sun, Mar 11, 2012 at 12:09 PM, Jacob Kaplan-Moss <ja...@jacobian.org>wrote:
> I've written such a pluggable User app. By default, the User model works
> as before. But I've also provided a User model (and forms, admin, backends,
> etc) implementation that removes the limitations of the User model noted
> above and allows for email authentication. It's still a bit rough around
> the edges, but it works, insofar that `manage.py createsuperuser` doesn't
> ask for a username, `manage.py changepassword` takes an email address, and
> I can login to the admin interface with my email address.
>
> Can you please post this code somewhere? I'd love to see it.
>
Sure, here's a fork of 1.4rc1 that allows for pluggable auth apps:
https://github.com/claymation/django/tree/pluggable-auth-apps
The patch is rather large, but represents mostly the movement of files, and
some refactoring of components to allow for greater reuse. For instance,
the User model (and the forms, decorators, backends, and middleware that
depend on it) has moved from django.contrib.auth to a new app,
django.contrib.auth.default. This new app represents the default pluggable
auth app, as reflected by the default value of the AUTH_APP setting (in a
manner similar to the COMMENTS_APP setting).
Backwards compatibility is maintained by continuing to honor the existing
import contract, e.g., `from django.contrib.auth.models import User`. User
is defined at run-time to be either the default
(django.contrib.auth.default.models.User), or a user-provided model, based
on the value of AUTH_APP. With the exception of having to add the new
django.contrib.auth.default app to INSTALLED_APPS, existing django
installations should be unaffected by this change.
New django projects can elect to use an entirely different pluggable auth
app, by setting AUTH_APP and adding such app to INSTALLED_APPS. Any library
or bespoke code that imports User from django.contrib.auth.models will get
the new model. The burden of ensuring that third-party and bespoke code is
compatible with the new User model will fall on the author of that model.
In other words, if I export a User model with no username field, I
shouldn't expect that model to work in tandem with a blogging app that
requires a username field.
To simplify the process of writing new pluggable auth apps, I've factored
out some common functionality from django.contrib.auth.default and put it
in django.contrib.auth.base. These base models are intended to be an aid to
reuse, but are not required, and have no special properties.
As an example of a pluggable auth app, here's one I wrote that allows for
email authentication:
https://github.com/claymation/django_email_auth
The pluggable-auth-apps fork is barely two days old, so it's still rough
around the edges, and I've almost certainly missed some things. I haven't
written any new tests for it yet, but the existing suite passes—at least
the tests that aren't skipped. I've installed all the requirements listed
in the testing docs—including selenium—but I get:
----------------------------------------------------------------------
Ran 4639 tests in 438.865s
OK (skipped=72, expected failures=2)
If this approach looks like something we might want to move forward with,
I'll start working on some tests and docs.
Cheers,
Clay
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
