Jorge Vargas wrote:
> 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
>> and also get feedback from you.
>> First of all, please keep in mind that repoze.what's goal is to support
>> 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
>> 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 ?
This separation makes sense to me; repoze.what middleware should be able to
consume environment variables from any old middleware doing authentication
"above" it in the WSGI pipeline. This makes it possible to use repoze.what
independently from repoze.who, which lets people a more piecemeal approach to
integration (maybe you already have Apache doing authentication for you, for
Repoze-dev mailing list