[PEAK] peak.security refactoring; anybody using?

Phillip J. Eby pje at telecommunity.com
Tue Nov 23 19:08:40 EST 2004


Is anybody using any deeper aspects of peak.security, beyond trivial 
security.Anybody/security.Nobody declarations?  Specifically, are you or 
have you:

* Implemented IAuthorizedPrincipal in your "user" objects?

* Implemented IPermissionChecker directly?

* Implemented OR used any of the IGuardedXYZ interfaces in any way?

* Created any RuleSet subclasses, or used the 'declareRulesFor()' method?

* Done any extension of the PermissionType class?

If any of the above apply, please let me know.  I'd like to refactor, such 
that all of the above become irrelevant, replaced with a couple of generic 
functions in the security.Interaction class.  This is another one of those 
places where I could probably do it in a backward-compatible way if I 
worked at it, but if nobody's making deep usage of it yet, it would be much 
easier to just throw out the old stuff.

Anyway, the new API will probably just consist of two generic functions: 
one to determine what permission is needed for a given attribute name on a 
given object, and one to determine whether a given user has a permission in 
relation to some object.  By either adding methods to the global generic 
functions, or in subclasses of security.Interaction, you'll be able to 
create either global or context-specific security rules.  Best of all (from 
my POV anyway), something like 70% of the current peak.security code (aside 
from interfaces and test suites) will just disappear like it was all a 
dream.  :)




More information about the PEAK mailing list