Thanks for asking this question, by the way, I have added it (and a
variation on my answer) to the "design defense" documentation that is
present in BFG:
(The rendered version, which doesn't yet include the above addition is
available at http://docs.repoze.org/bfg/1.3/designdefense.html).
On Wed, 2010-07-28 at 12:09 -0400, Chris McDonough wrote:
> 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
> > Repozefirstname.lastname@example.org
> > http://lists.repoze.org/listinfo/repoze-dev
> Repoze-dev mailing list
Repoze-dev mailing list