On Tue, Jan 6, 2009 at 1:51 PM, Gustavo Narea <m...@gustavonarea.net> wrote:
> Hello, everybody.
> I've already started the development of the next major release of repoze.what
> (initially labeled as v1.5), v2.0, and I wanted to let you know about my plans
> and also get feedback from you.
> First of all, please keep in mind that repoze.what's goal is to support common
> authorization patterns out-of-the-box, but *never* have a default/preferred
> The enhancements I have in mind are:
> repoze.who independence
> Many people have requested this, but repoze.what v1 is the successor of
> tgext.authorization (former tg.ext.repoze.who; an authorization and
> authentication framework), whose dependence on repoze.who was high and when
> development started such a featured was not requested... so it was late to
> introduce it in v1.
> Plus, initially I wanted to take advantage of repoze.who's plugins (specially,
> mdproviders and challengers) to inject some functionality in the future, but
> now I realize that it's best for repoze.what to have its own middleware.
> So, authorization patterns that rely on the user's identity (such as the
> groups/permissions-based one) will use REMOTE_USER or a custom key in the
> environ to get the authenticated user's Id.
This is the only bit that bothers me. Could you express why repoze.who
is "bad"? which is the alternative? does this means repoze.what will
grow it's own repoze.who-like layer? When people "request this" which
authentication layer are they favoring, their own little thing? or
there is another mayor contestant that I'm not aware of ?
tgext.autorization was "deleted" in favor of repoze.what because of
it's integration with repoze.who, doesn't this goes against that
initial goal of integration? if this is the case then we may as well
go back to tgext.authorization, and just like TurboMail 3.0, states
that even though it's designed to work with TG it's wsgi enable and
you can use it everywhere. I'm just puzzled as to where things should
go, specially from the TG side of things as this package has hopped a
lot in the last flew months which is not good for PR, and horrible for
keeping track of what has changed and documenting stuff.
Everything else seems wonderful.
I was writing a comment regarding the "role thing" but Chris email got
in, I agree with what he says, rather than role, a much wanted feature
(for me and others that have asked with myself present) is a
fine-grained access control to a resource, or row-level-ACL if you
want to put it dbwise.
Repoze-dev mailing list