There's a common task in systems using authentication and authorization, and
that's handling an authorization denial. However, I'm not sure if repoze.what
v2 should play a role in such a handling (v1 does not).
The way things work right now by default, when the WSGI application denies
authorization, repoze.who handles it by running a challenger (regardless of
whether the user has been authenticated or not).
So, I think it *might* be a good idea if repoze.what will handle such denials,
if and only if the user had been authenticated -- possibly implementing
repoze.who-like challengers. If the user is anonymous, then it'll get handled
by repoze.who (if you're using it; it won't be mandatory as of r.what v2).
This way we avoid displaying the login form to an already logged in user;
another solution is to write a repoze.who challenge decider.
But anyway, I think repoze.what v2 should support repoze.who-like challengers,
as sometimes authorization depends on an action from the user (on demand). For
example, if you have a WHOIS website you'll want people trying to access a
domain's data to demonstrate they're human by using a CAPTCHA (a repoze.what
plugin might provide CAPTCHA support using a repoze.what challenger which
displays a form with all the code for the user to answer the question and also
validate it). I see challenger plugins in repoze.what as the most extensible
way to deal with such situations.
So, should repoze.what v2 play a role handling authorization denials? If so,
Thanks in advance!
Gustavo Narea <http://gustavonarea.net/>.
Get rid of unethical constraints! Get freedomware:
Repoze-dev mailing list