Changes between Version 3 and Version 4 of GenericAuthorization
- Timestamp:
- May 28, 2006, 4:36:32 PM (19 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
GenericAuthorization
v3 v4 5 5 == Proposal == 6 6 7 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. {{{peak.security}}} http://peak.telecommunity.com/DevCenter/SecurityRuleswill be used as a basic model, but things will be made more django-like where it makes sense.7 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. 8 8 9 9 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: … … 55 55 {{{has_permission}}} will be implemented as a class with a {{{register}}} method and a {{{__call__(self, user, permission, object)}}} method. 56 56 57 This method is similar to Philip J. Eby's [ !RuleDispatch http://peak.telecommunity.com/PyCon05Talk/] and Guido van Rossum's recent work on generic/overloaded functions. See wiki:GenericAuthorization#Referencesfor 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.57 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. 58 58 59 59 … … 62 62 Here's a simple roadmap for this project. I'll try to keep it as up to date as possible, noting changeset numbers as tasks are completed. 63 63 64 || Task || Status||65 || Implement and test the has_permission generic function. || Not Started||64 || '''Task''' || '''Status''' || 65 || Implement and test the has_permission generic function. || In Progress || 66 66 || Implement a function to mimic Django's current authorization. || Not Started || 67 67 || Update the admin system to use {{{has_permission}}} and test. || Not Started || 68 68 || Update other views/decorators to use {{{has_permission}}} and test. || Not Started || 69 || Revise this page and integrate into core django docs. (Is this allowed for SoC, I'l let my mentor decide, if not, I'll just do it after SoC is over)|| Not Started ||69 || Revise this page and integrate into core django docs. || Not Started || 70 70 71 71