[Repoze-dev] Plans for repoze.what v2
me at gustavonarea.net
Tue Jan 6 12:51:29 EST 2009
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:
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 backwards incompatible change I have in mind, but it won't
affect projects using the quickstart plugin because it will continue
configuring both repoze.who and repoze.what (that's its goal).
The most frequently requested feature from non-TurboGears developers :)
The roles-based authorization pattern will be supported and it will be
optional, like the groups/permissions-based pattern as of v1.0-rc2.
Roles will be supported through so-called source adapters (like groups and
permissions), so developers will be able to store them in Ini or XML files, or
even databases. The relevant predicates will be provided too (i.e., has_role,
has_any_role and has_all_roles).
A new authorization pattern will be supported: one base on whether the current
current is a known spammer or the submitted contents are spam, according to
anti-spam services like Akismet or Defensio (each anti-spam service will be
supported by one plugin).
Two predicates will be provided:
* is_spammer: To check whether the current user is a known spammer. For
example, if you run a mailing list software with a web interface, you may want
to prevent potential spammers from getting the email addresses of the members.
* is_spam: To check whether the submitted content is spam. By default, it
will send the POST variables "message", "author_name", "author_email", among
others (when available), to the anti-spam service (like Akismet) to check
whether it's spam, but all this can be customized. For example, if you have a
blog and want to filter out potential spam comments.
And to avoid loosing information, contents marked as spam by the anti-spam
service will be added to the moderation queue (in a database, XML file, etc).
Most of this work is already done and tested, but not yet usable.
CAPTCHA-based authorization will be supported and it will be inspired by
repoze.who challengers (it's a very smart design which is extremely
extensible), with a CAPTCHA challenge decider and a CAPTCHA challenger (in
charge of providing the CAPTCHA image, audio, HTML, etc).
A CAPTCHA challenge can be requested using the is_human predicate, which you
can use, for example, in the action that processes the registration form. Then
the CAPTCHA challenge decider will run the CAPTCHA challenger, unless the
current user (most likely anonymous, but that's up to the developer) has
already passed a CAPTCHA challenge in the last 60 minutes (for example).
PS: Of course, contributors are very welcome!
Gustavo Narea <http://gustavonarea.net/>.
Get rid of unethical constraints! Get freedomware:
More information about the Repoze-dev