On Wed, 2010-07-28 at 16:58 +0200, Free Ekanayaka wrote:
> Hi,
> I'm starting to explore Repoze.bfg and I find it great.

Thanks for letting us know!

> Reading the documentation I gather that the default security model is
> "view-based", that means the authorization policy is basically defined
> and checked at the view level.
> If I understand it correctly, an __acl__ attribute on a context object
> is used to determine which permissions does a certain user or principal
> have on the object itself, and then a view for that context can define a
> permission which the user needs to have on the context object in order
> to access the view itself.
> I find it nice to have the authorization policy defined and checked at
> the view level. However comparing this approach with the model-based one
> of Zope 3 (that wraps context objects with a security proxy) I can see a
> few shortcomings that I'm not sure how to deal with:
> 1) Let's say that I want to also expose my model via a REST API, and I
> want to use Twisted Web for that. Though I can probably reuse the
> __acl__ attributes on the model objects, I have to implement a new set
> of "view-level" authorization definitions for the API. On the other side
> using Zope3's security proxy, I would enforce my authorization policy
> both on Repoze.bfg's views and in the Twisted-based API transparently
> and in the same way.
> 2) With the security proxy machinery I can have a view that
> conditionally displays certain HTML elements (like form fields)
> depending on the permissions that the accessing user has on the context
> object.
> 3) Similarly to 2) I can also have a single view that processes a
> request with parameters for performing a set of modifications on certain
> context object. It might be that the accessing user doesn't have all the
> necessary permissions to perform the requested modifications, and the
> security proxy machinery would raise an Unauthorized, however if the
> accessing user is effectively requesting only modifications for which he
> has permissions, the request would succeed.
> Now, what would be the recommended approach to deal with such use-cases
> in Repoze.bfg?

BFG was developed by folks familiar with Zope2, which has a "throwugh
the web" security model which was the precursor to Zope 3's security
proxies.  At the time I started to write BFG, I had created many Zope 2
sites (along with my partners at Agendaless, and before that at Zope
Corp).  Over time, as we created these sites, we found authorization
checks during code interpretation useful in some projects.  But much of
the time, those authorization checks usually slowed down the development
velocity of projects that had no delegation requirements.  In
particular, if we weren't allowing "untrusted" users to write arbitrary
Python code to be executed by our application, the burden of "through
the web" security checks proved too costly.  I personally haven't
written an application on top of which untrusted developers are allowed
to write code in many years.

And since we tend to use the same toolkit for all web applications, it's
just never been a concern to be able to use  the same set of
restricted-execution code under two web different frameworks.

> Would it possibly make sense to implement some repoze.what plugin for
> supporting Zope 3's security proxies?

In general, given that Zope 3 security proxies are viral, it is possible
to override the BFG "traverser" (see
plugging in a different traverser which returns security-proxy-wrapped
objects.  This would have the effect of creating a more Zope3-like
environment without much effort.

repoze.what is unrelated to BFG.  See the "Warning" near the top of
http://docs.repoze.org/bfg/1.3/narr/security.html .

> Grok seems to have opted for a view-based security model as well, by
> default, an interesting reading that touches some of the concerns
> expressed above can be found here:
> http://faassen.n--tree.net/blog/view/weblog/2008/04/17/0
> Cheers!
> Free
> _______________________________________________
> Repoze-dev mailing list
> Repoze-dev@lists.repoze.org
> http://lists.repoze.org/listinfo/repoze-dev

Repoze-dev mailing list

Reply via email to