[Repoze-dev] Plans for repoze.what v2

[Gustavo Narea]

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

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

Roles support
=============

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

Anti-spam pattern
=================

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 pattern
===============

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

==============

Feedback?

Cheers!

PS: Of course, contributors are very welcome!
-- 
Gustavo Narea <http://gustavonarea.net/>.

Get rid of unethical constraints! Get freedomware:
http://www.getgnulinux.org