Kevin Dangoor wrote:
On 1/11/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
Kevin Dangoor wrote:
Jeff has designed an identity API that is amazingly user friendly for
common cases. I would like to brainstorm a bit on how this API might
be tweaked to use RuleDispatch syntax which would provide more
flexibility going forward. That brainstorming should be in a separate
thread. I'd like to do that brainstorming before 0.9, because I'd
rather not have such a large backwards-incompatible change afterwards.
If you are thinking about RuleDispatch, you should probably consider
peak.security: http://peak.telecommunity.com/DevCenter/SecurityRules
Yep, I've looked at that. What I go after, design-wise, with
TurboGears APIs is that they should be super simple for the common
case and, as much as possible, provide a graceful migration path
upwards as needs get more complex. That's a tough balancing act, but I
also think that doing that well (or at least trying to!) leads to the
best possible product.
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.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
