Gustavo Narea wrote:
>> I'm not sure *just* adding roles really cuts it for maximum generality.
>> Maximum generality may not be a goal here, however, and that's your call.
>> But I'll note that roles granted to users or groups seems to be just
>> another way to spell global assertions.
>> A common thing to want to do is be able to make security assertions against
>> a *particular resource* (which might be represented as PATH_INFO in a URL,
>> or some object in a graph, or whatever). For example, you'd like to be
>> able to say that ("joe has permission to edit blog entry 1" and "joe cannot
>> edit blog entry 2") instead of "joe has permission to edit blog entries"
>> and then relying on imperative controller logic or decorators in the
>> downstream app itself to figure out whether joe has permission to edit
>> *this* blog entry.
> You can achieve that with repoze.what predicates. You can write your own
> predicate to check for that condition:
> # process the post edition...
Apologies, I had too much to say about this topic to confine it to this reply.
Since we're talking about repoze.what staying middleware, I'm not sure how to
get truly general and truly declarative context-sensitive security without
creating something that resembles decsec in some way. This is the reason I
personally quickly gave up on trying to create a general-purpose athorization
framework for arbitrary WSGI apps: there are very few people who are willing to
deal with the control inversion that any maximally general system would impose.
That's not to say that "aiming lower" isn't useful to a huge swath of people: it
definitely is! But I'd like repoze.what to be something that *I* could
eventually use in a way that feels familiar and "right" (call me selfish).
>> I came up with a pattern for this in repoze.decsec (proposal at
>> http://www.plope.com/Members/chrism/decsec_proposal and implementation
>> notes at http://www.plope.com/Members/chrism/decsec_revisited). It's too
>> frameworky for general purpose use but it is implemented and described.
> Those documents are rather interesting. ACLs are a good alternative to
> predicate-based assertions, *and* I think they are not mutually exclusive.
The components used in the check aren't really all that important to me. I used
ACLs in decsec (and in BFG) because the implementation was straightforward and
pretty flexible. But the argument was mostly about being able to service
applications that required *context-sensitivity* during security checks in
repoze.what, not using ACLs to store the data that will be checked.
(sorry for the big snip here, there may be some interesting ideas there)
> Anyway, did I get it right? Is ACL support what you were proposing
> specifically? :)
No. I should have made it more clear I was talking about context-sensitive
assertions rather than ACLs.
>>> Anti-spam pattern
>> I'm not sure what this has to do with authorization. This seems like it
>> should be a separate system.
>>> CAPTCHA pattern
>> Same observation here: this sounds like it should be a separate system.
> I think that if a given routine is performed based on whether the current
> is a known spammer (or if a submitted content is spam), according to an anti-
> spam service, then that's an authorization pattern.
> Likewise, I think that if a given routine is performed based on whether we
> certain that the current user is human, then that's another authorization
OK, I still don't agree but I don't have enough "skin in the game" to make any
compelling argument against this.
> And because both authorization patterns are widely used, I think they should
> be supported out-of-the-box, *although* I wouldn't mind to implement such
> functionalities in two independent packages, as repoze.what plugins that
> provide the predicates mentioned above.
Making them plugins would fit my brain, sorta.
Repoze-dev mailing list