Changes between Version 10 and Version 11 of GenericAuthorization


Ignore:
Timestamp:
Nov 6, 2006, 4:20:30 PM (18 years ago)
Author:
jkocherhans
Comment:

updated status

Legend:

Unmodified
Added
Removed
Modified

  • GenericAuthorization

    v10 v11  
    11= Authorization =
    2 
    3 [[TOC(inline, GenericAuthorization)]]
    42
    53== Current Status ==
    64
     5The tests could be expanded, but the basic functionality is there.
     6
    77''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]
    8 
    9 {{{has_permission}}} has been implemented, and a set of tests for model-level permissions are complete. Unfortunately, subversion is all wacky and won't let me merge changes from the trunk. I don't have time to fight with it, so I'm just doing this as a [http://code.djangoproject.org/attachment/wiki/GenericAuthorization/generic-auth.diff patch] against the trunk for now. The tests pass, and I have tested the admin system integration. There's probably some debug code that still needs to be ripped out. Consider yourself warned ;)
    10 
    11 '''[http://code.djangoproject.org/attachment/wiki/GenericAuthorization/generic-auth.diff View Current Patch]'''
    128
    139== Proposal ==
    … …  
    6157}}}
    6258
    63 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 was we can use different functions for different models, custom user classes, and even custom permission types.
     59Now 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.
    6460
    6561This 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.)
    … …  
    7874|| Implement a function to mimic Django's current authorization. || '''Complete''' ||
    7975|| Update the admin system to use {{{has_permission}}} and test. || '''Compete''' ||
    80 || Update other views/decorators to use {{{has_permission}}} and test. || ''In Progress'' ||
     76|| Update other views/decorators to use {{{has_permission}}} and test. || '''Complete''' ||
     77|| Refactor {{{django.contrib.auth.models.User.has_perm}}} || ''In progress'' ||
    8178|| Revise this page and integrate into core django docs. || Not Started ||
    8279
Back to Top