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.
http://www.plope.com/control_inversion
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
>>> =================
>> <<<snip>>>
>>
>> I'm not sure what this has to do with authorization. This seems like it
>> should be a separate system.
>>
>>> CAPTCHA pattern
>>> ===============
>> <<<snip>>>
>>
>> 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
> user
> 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
> are
> certain that the current user is human, then that's another authorization
> pattern.
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.
Thanks,
- C
_______________________________________________
Repoze-dev mailing list
[email protected]
http://lists.repoze.org/listinfo/repoze-dev
