I'm starting to explore Repoze.bfg and I find it great.
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
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
Would it possibly make sense to implement some repoze.what plugin for
supporting Zope 3's security proxies?
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:
Repoze-dev mailing list