On Tuesday November 25, 2008 07:18:56 Dalius Dobravolskas wrote:
> repoze.what: Looks like TurboGears 1. The main mistake makes everyone
> when they implement authorization plugin/middleware, they think that
> everyone builds social networks or simple sites where you have users
> in groups with roles. In real world that does not work sometimes. I
> think it much better to leave control for user:
> http://trac.sandbox.lt/auth/wiki/AuthorizeMiddleware

I guess you've only read the outdated documentation at static.repoze.org. I'm 
currently preparing the first beta and the new documentation, but here's an 
excerpt from the main page:

> .. topic:: Overview
>
>     :mod:`repoze.what` is an `authorization framework` for WSGI
>     applications, based on :mod:`repoze.who` (which deals with
>     `authentication`).
>
>     On the one hand, it enables an authorization system based on the 
>     groups to which the `authenticated or anonymous` user belongs and 
>     the permissions granted to such groups by loading these groups 
>     and permissions into the request on the way in to the downstream
>     WSGI application.
>
>     And on the other hand, it enables you to manage your groups 
>     and permissions from the application itself or another program, under 
>     a backend-independent API. For example, it would be easy for you to
>     switch from one back-end to another, and even use this framework to
>     migrate the data.
>
>     It's highly extensible, so it's very unlikely that it will get in 
>     your way. Among other things, you can extend it to check for many 
>     other conditions (such as checking that the user comes from a 
>     given country, based on her IP address, for example).
>
>
> Features
> ========
>
> Unless mentioned otherwise, the following features are available in
> :mod:`repoze.what` and its official plugins:
>
> * ``Web framework independent``. You can use it on any WSGI
>   application and any WSGI framework (or no framework at all). Web
> frameworks may provide integration with it (like `TurboGears 2
>   <http://turbogears.org/2.0/docs/>`_, which features a strong integration
> with :mod:`repoze.what`).
> * ``Authorization only``. It doesn't try to be an all-in-one auth
>   monster -- it will only do `authorization` and nothing else.
> * ``Highly extensible``. It's been created with extensibility in mind, so
>   that it won't get in your way and you can control authorization however
> you want or need, either with official components, third party plugins or
> your own plugins.
> * ``Fully documented``. If it's not described in the manual, it doesn't
> exist. 
> * ``Reliable``. We are committed to keep the code coverage at 100%.
> * ``Control access to any resource``. Although it's only recommended to
> control authorization on action controllers, you can also use it to
> restrict access to other things in your package (e.g., only allow access to
> a database table if the current user is the admin).
> * Your application's `groups` and `permissions` may be stored in an
> SQLAlchemy managed database, thanks to the SQL plugin
> (:mod:`repoze.what.plugins.sql`). 
> * The only requirement is that you use
> the powerful and extensible `repoze.who
> <http://static.repoze.org/whodocs/>`_ authentication framework.
> * `It's not hard to get started!`
>
>
> And according to the to-do list, we *will* have official plugins to:
>
> * Enable `OAuth <http://oauth.net/>`_ support.
> * Enable authorization based on certain network conditions
>   (e.g., grant access if the user's IP address belongs to a given IP range,
>   deny access if the user's host name is "example.org", grant access based
> on the user's ISP).
> * Enable authorization based on `client-side SSL certificates
>   <http://en.wikipedia.org/wiki/X.509>`_ (e.g., allow access if the
>   `Certificate Authority` is XYZ, allow access if the user is called "John
>   Smith" or "Foo Bar").
> * Enable authorization based on LDAP attributes of the authenticated user's
>   entry (e.g., allow access if the user can be reached at a cellular phone,
>   allow access if the user belongs to the "ABC" organization).
> * Enable a highly extensible `CAPTCHA
> <http://en.wikipedia.org/wiki/CAPTCHA>`_ driven authorization mechanism to
> restrict access to a given resource (possibly the hardest to create
> plugin).
> * Store groups in ``Htgroups`` and ``ini`` files, and re-use LDAP
>   `Organizational Units` as groups.
> * Store permissions in ``ini`` files.

Oh, and it already provides a module to get started very quickly with 
repoze.who and repoze.what at the same time, which is used in TurboGears 2.

Cheers.
-- 
Gustavo Narea.
General Secretary.
GNU/Linux Matters <http://gnulinuxmatters.org/>.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to