(Phew, finally I had the time to continue this thread.)

On Wednesday January 7, 2009 07:04:20 you wrote:
> > 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).

OK, now I think I understand what you meant, specially after reading your 
comment to the article above whose title is "swappability".

Your suggestion sounds sensible to me and I'm willing to make the 
authorization pattern available through decsec in repoze.what, along with the 
groups/permissions-based pattern.

The use cases where one of the two patterns would be useful depend on the 
developer's likes, but there are several use cases that come to my mind in 
which *both* patterns would be useful in the same application. One of them is 
a CMS whose actions use repoze.what predicates (using the groups/permission 
pattern), *but* its administration interface provides a friendly interface to 
customize authorization using the context-sensitive pattern (e.g., the CMS 
allows people with the "edit-page" permission to edit any page in the website, 
but the admin may enforce that the "Jobs" page could only be edited by people 
in the HR group).

> > 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.

OK, I'll take it into account.

> > 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.

OK, then they won't be in the core.

Gustavo Narea <http://gustavonarea.net/>.

Get rid of unethical constraints! Get freedomware:
Repoze-dev mailing list

Reply via email to