= Authorization =

== Current Status ==

The tests could be expanded, but the basic functionality is there.

''The current auth context processor isn't going to work as-is. has_permission should take the object you're working with as an argument, but there's no way to get it without changing the way context processors work. I think some sort of template tag ought to replace the auth context processor, but I'm not sure what it should look like yet. Chris Long (the per-object-permissions author) has a proposal [http://groups.google.com/group/django-developers/browse_thread/thread/d380813d611f5ccb/8d7259f1c8f7b0e0#8d7259f1c8f7b0e0 here]

== Proposal ==

As part of Google's 2006 Summer of Code, Joseph Kocherhans will be implementing a more flexible authorization system for Django. The new system should allow for ACL's, role-based systems, and Django's current model-level permissions. [http://peak.telecommunity.com/DevCenter/SecurityRules peak.security] will be used as a basic model, but things will be made more django-like where it makes sense.

Currently Django's authentication system is tied directly to the User model from django.contrib.auth. Also, there is no way to allow for row-level permissions. Authentication checks will be changed to use a new generic function:

{{{
#!python
has_permission(user, permission, object)
}}}

This function will delegate to other functions based on the type of user, permission and object that are passed to it. This will allow the use of different types of security rules depending on the type of object being accessed, as well as allowing for new user objects that don't need to fulfill the whole {{{django.contrib.auth.models.User}}} interface. You can even create rules that don't depend on the default permission table in the database.

== Scope ==

The scope of this project is limited to providing the underlying support for making ACL's, etc possible, not actually implementing such policies. A policy that mimicks Django's model-level permission system will be included though.


== Usage ==

=== Checking a permission ===

{{{
#!python
from django.contrib.auth import has_permission
if has_permission(user, permission, object):
    # do something
}}}


=== Adding new rules ===

Here's an example of the low level api for adding new security rules. In reality, this will probably happen under the covers via new Meta settings, but this will be discussed later, probably after the low level stuff has been implemented and tested.

{{{
#!python
from django.contrib.auth.models import User, Permission
from django.contrib.auth import has_permission

class Person(models.Model)
    name = models.CharField(maxlength=50)

    class Admin: pass

def default_has_permission(user, permission, object=None):
    return user.has_perm(permission)

has_permission.register(default_has_permission, User, Permission, Person)
}}}

Now every time has_permission is called with an instance of User, Permission, and Person, those argument will be passed into default_has_permission, and the result will be returned. This way we can use different functions for different models, custom user classes, and even custom permission types.

This is fairly close to what it would look like to implement django's current security policy. The object isn't really important in this case since Django's permissions are based on the Model you're accessing, not the actual object (See RowLevelPermissions for object-specific permissions.)

== Implementation ==

{{{has_permission}}} will be implemented as a class with a {{{register}}} method and a {{{__call__(self, user, permission, object)}}} method.

This method is similar to Philip J. Eby's [http://peak.telecommunity.com/PyCon05Talk/ RuleDispatch] and Guido van Rossum's recent work on generic/overloaded functions. See [wiki:GenericAuthorization#References References] for examples. The plan is to start out with a really naive and simple implementation, if it works and performs reasonably it should probably be left simple.


== Roadmap ==

|| '''Task''' || '''Status''' ||
|| Implement and test the has_permission generic function. || '''Complete''' ||
|| Implement a function to mimic Django's current authorization. || '''Complete''' ||
|| Update the admin system to use {{{has_permission}}} and test. || '''Compete''' ||
|| Update other views/decorators to use {{{has_permission}}} and test. || '''Complete''' ||
|| Refactor {{{django.contrib.auth.models.User.has_perm}}} || ''In progress'' ||
|| Revise this page and integrate into core django docs. || Not Started ||

== References ==

 - http://svn.python.org/view/sandbox/trunk/overload/
 - http://www.artima.com/weblogs/viewpost.jsp?thread=155123
 - http://www.artima.com/weblogs/viewpost.jsp?thread=155514