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
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Reply via email to