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 _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
