Gustavo Narea 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 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).
That sounds fine, as repoze.who does indeed set REMOTE_USER, and the
relationship between what and who right now is a little weird (what is
essentially a superset of who, which makes me a little nervous). Splitting them
apart seems about right.
> 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,
> even databases. The relevant predicates will be provided too (i.e., has_role,
> has_any_role and has_all_roles).
I'm not sure *just* adding roles really cuts it for maximum generality. Maximum
generality may not be a goal here, however, and that's your call. But I'll note
that roles granted to users or groups seems to be just another way to spell
A common thing to want to do is be able to make security assertions against a
*particular resource* (which might be represented as PATH_INFO in a URL, or some
object in a graph, or whatever). For example, you'd like to be able to say that
("joe has permission to edit blog entry 1" and "joe cannot edit blog entry 2")
instead of "joe has permission to edit blog entries" and then relying on
imperative controller logic or decorators in the downstream app itself to figure
out whether joe has permission to edit *this* blog entry.
I came up with a pattern for this in repoze.decsec (proposal at
http://www.plope.com/Members/chrism/decsec_proposal and implementation notes at
http://www.plope.com/Members/chrism/decsec_revisited). It's too frameworky for
general purpose use but it is implemented and described.
> Anti-spam pattern
> A new authorization pattern will be supported: one base on whether the
> 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
> 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.
I'm not sure what this has to do with authorization. This seems like it should
be a separate system.
> 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.
> 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).
Same observation here: this sounds like it should be a separate system.
Repoze-dev mailing list