"Phillip J. Eby" <[EMAIL PROTECTED]> writes: > The other benefit of course is indirection. Since permissions are > separated from the authentication and authorization rules, it allows > you to distribute an application component that can be customized > without changing its source. The security rules are determined by > context, not by hardcoding. It also allows you to avoid repetition, and > encourages thinking about access control in terms of users and use > cases rather than in terms of individual operations. And even if an > application defines default permissions and rules, these can still be > overridden in a particular deployment by subclassing the context and > defining new operation-to-permission or permission-to-user rules. > > Anyway, these are not necessarily benefits for TurboGears' audience; > I'm just pointing out for the sake of anybody following this thread > what the intended benefits of peak.security are, so they can tell for > themselves whether eval() is indeed better for *their* use cases. :)
I definitely hope that this gets into TG soon... That's OK for post-0.9, but I really like the idea of not repeating a lot of code -- even if they are like decorators -- and thinking in use cases / users. Today's operation-based thinking solves the problem for small requirements but it gets a lot in the way for more complex applications. -- Jorge Godoy <[EMAIL PROTECTED]>
