On Thu, Mar 25, 2010 at 4:27 PM, d3f3nd3r <d3f3n...@bytegeist.org> wrote: > Hello everyone, > > I'm planning to apply for the GSoC Enhanced auth.user project. I > worked on several Django based projects before. > (hackerspace os (http://code.google.com/p/hackerspace-os/) is probably > the > biggest one (used by the Austrian hackerspace metalab (http:// > metalab.at)) and > a lot of smaller ones) > > I faced some limitations of the auth framework when I tried to write a > custom > auth backend for Django on Google App Engine (http://bitbucket.org/ > d3f3nd3r/djangoappengine-helpers/). The problem was, that > the auth framework forces you to call a login() function when the > user logs in and set request.session[SESSION_KEY] and > request.session[BACKEND_SESSION_KEY]. > > When using Google Accounts for authentication no django login > method is called. But django.contrib.auth.__init__ get_user() method > depends on > request.session[SESSION_KEY] and request.session[BACKEND_SESSION_KEY] > so a > custom backend with a custom get_user() won't work without a modified > middleware. > (http://groups.google.com/group/django-non-relational/browse_thread/ > thread/36b760c515b75c0e) > > My first approach to make the auth system more flexible is to make the > methods > in django.contrib.auth.__init__.py more flexible, so the methods > doesn't force > you to call a django login method. All backends will have to extend a > base > backend class and implement the get_user(), login(),.. methods. > The request.session stuff will be moved to the ModelBackend (other > model based > backends can extend ModelBackend). So it will be easy to create custom > backends > for Google Accounts,Twitter, Facebook... that work out of the box with > the Django auth system. > > The second task will be to make the user model more extendable. I > think the > way suggested by David Danier > ( ticket : http://code.djangoproject.com/ticket/3011) is a good one. > Move > all the login and permission stuff to extra Permission and Auth base > classes. > A base model class for authentication will only contain an ident field > (we > dont't need to store user name / password/ email if we use a remote > service for > authentication, but we have to link the remote service user to to > Django user > model). The "old" contrib.auth.models.User class will extend the two > classes > (Permission and Auth) and add all the extra fields (username, first-, > last name....) so it won't break existing apps. > A list of accepted user classes can be passed to the backends. > > I know this is a tough issue, but I'm really interested in working on > the > problem. Please post your comments, ideas, suggestions,..., so we can > find a > good solution. (and maybe a successful proposal for GSoC)
First up, this is probably the most ambitious project on the proposal list. When I warn that this is a tough issue, I'm not kidding. This is gonna be *hard*. With a capital Huh. There are all sorts of technical issues, and a couple of political ones too. Still interested? Ok. Here's a few quick comments about your proposal. Firstly, Backwards compatibility. contrib.auth is a major component in many, if not most existing Django installations. If you're proposing *any* change, the existing code needs to be 100% backwards compatible. For example, I'm not entirely certain I follow why the changes to login() et al are necessary. You're proposing to change login(), etc, but you're a little light on details on how backwards compatibility will be maintained. (Related note - a proposal should be largely self contained. Links to mailing lists are OK if you need to show the evolution of an idea, but when it's the endpoint idea that is important, your proposal should contain a concise summary of that endpoint) Also, if you're proposing that the auth.User model be refactored, you're going to need to demonstrate why existing auth.User installs aren't going to be affected. Secondly, as far as I can make out, your proposal doesn't address the biggest problem I can see -- Foreign Keys/ManyToMany to User. It isn't much good proposing a way to use a different User model if you don't provide a way for other applications that currently ship with a ForeignKey to contrib.auth.User to change that into a ForeignKey on your new User model. The approach used by contrib.Comments with COMMENTS_APP may be worth investigating here. A related problem here: what happens if a developer changes their User model during the development process? How do I migrate my existing contrib.auth users to use mycustom.auth users? Is this even possible? Is there any way to protect against this class of error? Another related problem - even if you make User pluggable, there will still be a need for some common interface for user-like objects. What should be on this interface? Lastly, what is the impact on other areas of Django code? Backwards compatibility means that all existing code must continue to work as-is, but if we're shipping a new capability, all the built-in Django code should be updated to use that new capability. When we rolled out the new messages model, we had to modify admin and auth to use the new messages. What aspects of Django currently use the User model and will need to be updated? So - if I haven't scared you off yet, I'm certainly interested in hearing more details. This is one of the really big project flexibility issues in Django, and I for one am certainly interested in seeing it fixed. However, the devil is in the details. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
