[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
* 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
More information about the PEAK