Customizable User model as GSoC project
Edward Kaplan
replaceable User model in auth_user as a Summer of Code project. I am
personally interested in this feature because it would have allowed a
cleaner design in a Django project I worked on, but I also believe
from reading discussions on the topic that it would be useful to a
large number of other Django users.
The situation in which the feature would have been useful to me was
that I needed to synchronize the User model in my project with Google
Apps. Rewriting the default auth views seemed like overkill, as I
only wanted to override the set_password and create_user methods to
send updated passwords to Apps before they are hashed. My solution
involved ugly monkeypatching and being able to specify my own model
would have been more desirable.
I would like to know if this would be considered for a SoC project.
Please let me know if you have any comments or suggestions on how to
improve the idea.
Thanks,
Ted K
Russell Keith-Magee
>
> Hello, I am a student interested in implementing an extendable/
> replaceable User model in auth_user as a Summer of Code project.
> I would like to know if this would be considered for a SoC project.
A very tentative, in principle, maybe.
> Please let me know if you have any comments or suggestions on how to
> improve the idea.
First off, we need an idea. You have told use what you are interested
in. You have told use why you are interested. You have told us the
workaround that you implemented (based on monkeypatching). What you
haven't given us is any sort of proposal of what are proposing to fix
- and more importantly, how you are proposing to fix it.
In principle, yes - contrib.admin should be decoupled from
contrib.auth. It should be possible for any external authentication
module to be used in the place of contrib.auth, provided the
replacement module overrides some methods or adheres to some common
interface.
However (as I very deliberately put on my dumb person hat), I'm not
convinced that this isn't already possible. If you grep the
newforms-admin source code, there are only a handful of imports of
contrib.auth and most of the usages of auth are wrapped in methods
that can be overridden as an end user. There may be a documentation
hole that needs to be filled, but GSoC doesn't cover pure
documentation upgrades.
If I'm wrong (and I'm sure I am), and you want to convince us that
this is a project worth sponsoring, then you need to give us _concrete
suggestions_, not just a hand wave "make everything 20% betterer".
What parts of the admin are currently locked to contrib.auth? What do
you propose to improve? change? fix?
Yours,
Russ Magee %-)
zellyn
> The situation in which the feature would have been useful to me was
> that I needed to synchronize the User model in my project with Google
> Apps. Rewriting the default auth views seemed like overkill, as I
> only wanted to override the set_password and create_user methods to
> send updated passwords to Apps before they are hashed. My solution
> involved ugly monkeypatching and being able to specify my own model
> would have been more desirable.
We just integrated our Django auth with a centralized auth server
(written in-house in Merb, actually). We needed to override get_profile
(), save(), check_password(), and set_password() to act against the
centralized store. We also needed to create a new auth backend, and
create generic ways to do things like check whether an email address
was already taken (rather than User.objects.get(email=email), etc.)
The easy, pluggable part is the authentication backend. We runtime-
monkey-patch the User objects, and created our own auth views and
forms. I think the built-in auth views and forms are useful as
examples: few of the auth-related projects I've looked at use the
built-in views. We also created a mostly-complete copy of the reset-
password views that accept a "next" URL parameter, and pass it around.
(This latter I should bundle up as a patch to django: it's self-
contained and reasonably clean.)
I think Django 1.1's proxy models might cut down on the monkey-
patching. However, I don't think the auth backends are the only code
that instantiates contrib.auth.models.User objects.
Hopefully we're doing it all wrong, and someone here will point us
towards a simple, clean approach…
Good luck!
Zellyn Hunter
The Atlanta Journal-Constitution
Richard Silver
David Danier
perhaps take a look at ticket #3011
(http://code.djangoproject.com/ticket/3011).
Greetings, David Danier