Kevin Dangoor wrote: > On 12/27/05, Jeff Watkins <[EMAIL PROTECTED]> wrote: > > Many people wanted something more flexible, and with revision 400, > > any of the following are valid require decorators: > > > > @identity.require( in_group( "admin" ) ) > > @identity.require( in_all_groups( "admin", "editor" ) ) > > @identity.require( in_any_group( "admin", "editor" ) ) > > @identity.require( has_permission( "edit" ) ) > > @identity.require( has_all_permissions( "edit", "delete", > > "update" ) ) > > @identity.require( has_any_permission( "edit", "delete", > > "update" ) ) > > > > But most importantly, you can use decorators like theses: > > > > @identity.require( Any( in_group( "admin" ), has_permission > > ( "edit" ) ) ) > > @identity.require( All( from_host( "127.0.0.1" ), has_permission > > ( "edit" ) ) ) > > @identity.require( All( from_any_host( "127.0.0.1", "10.0.0.1" ), > > in_group( "editor" ) ) ) > > This is cool. I wonder, though, if there's a way we can do this by > getting RuleDispatch in the mix. RuleDispatch is *very* fast and > flexible.
See also: http://peak.telecommunity.com/DevCenter/SecurityRules which is an "access control rules" library based on RuleDispatch. The source code for the module (less than 200 lines!) is here: http://svn.eby-sarna.com/PEAK/src/peak/security/rules.py?rev=1978&view=markup If you lop off the interface declarations and the 'binding'-decorated functions at the end of it, the code will not introduce any PEAK-specific dependencies except for RuleDispatch. (Heck, if you want, I could just as easily spin this off into its own egg.) Note that it would still be possible to use the existing @identity.require() helpers, they could just translate to expression strings that would get passed to RuleDispatch under the hood.
