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:
http://lists.repoze.org/pipermail/repoze-checkins/2010-July/009583.html (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 > http://docs.repoze.org/bfg/1.3/narr/hooks.html#changing-the-traverser), > 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 > Repoze-dev@lists.repoze.org > http://lists.repoze.org/listinfo/repoze-dev > _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
