On 1/11/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> I think the basic setup would be a set of rules based on data. The data
> might look like:
>
> {
> '/admin': ['admin', 'editor'],
> '/comment': ['valid-user'],
> }
>
> And a rule would check if the URL was prefixed by something in that
> dictionary, and check against the roles for that URL. Another
> complimentary option would be to add the resource (exposed object) to
> the context of the action, and use an attribute on that to indicate
> roles. These rules can probably just be installed globally, and then
> specialized if necessary, especially because there's the two-phase
> aspect of peak.security -- the rules indicating whether a function even
> applies, and then an indication about whether the user is then
> permitted. So these default rules would, if the user didn't use them
> (implementing their own system) simply not apply.
My thought is to maintain the same basic idea that Jeff has come up
with: when locking down a single method, put the lock right there
(with a decorator). When locking down an object or tree, put the lock
right on that class. Use an external configuration system for it only
as needed (and many apps don't need it).
Kevin
