Jeff Watkins wrote:
It has to be said however that some things could be solved more
elegantly. Here peak.security shines.
Exactly. But what things? Which things need cleaning up? I can't tell
because I'm too close to the code.
1) Predicates make Identity essentially a DSL for Boolean algebra which
is already covered quite nicely in Python itself. Mixing infix and
prefix notations is not all that aesthetical either.
One possible solution (besides RuleDispatch) would be to make all
relations monads.
2) In most cases there tends to be just a few sets of rules applied to
many methods. The way Identity currently works this makes for a lot of
code multiplication and opens a new frontier for bugs.
3) If Paste and WSGI applications mixing gain a foothold in TG it would
be nice to have the security model decoupled as much as possible.
Ideally it would be a separate layer altogether. My gripe #2 becomes
even more pressing here as using Identity in current form means
spreading security declarations throughout not just methods but
applications.
Kevin Dangoor wrote:
> I'm also envisioning that identity.require *could* take a Context
> object directly instead of a string, which provides a super simple
> extension point for people when it comes to authorization: just define
> your own context and use it wherever you need to.
Context and optionally a binding for user, perm or subject. This way we
retain the flexibility of peak.security's loosely defined symbols.
Cheers,
Simon
