Re: [Repoze-dev] Model-based vs. view-based security
Hi Tim, |--== On Thu, 29 Jul 2010 07:36:57 +0800, Tim Hoffman zutes...@gmail.com said: TH Hi 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. TH I too came to bfg from zope2 and zope 3 and was used to model based TH security, TH however the complete disconnection of forms from models in bfg is just TH fantastic ;-) Yeah, I'm fascinated by that as well, and I'm trying to understand how it could fit the requirements I need to meet. TH I always found that whilst forms tied to the model was nice for simple TH things (ala basic crud) the minute TH you had complex forms (aggregate forms, forms with no model etc) that the TH tight binding of model and form was TH a big pain. Separating form from model has been a real godsend for some of TH my latest projects. I agree that model objects and forms are not generally tight together, even though I'd argue that virtually every web application will need basic CRUD for the core entities. TH I use a UML modeling tool to generate all my models and form schemas so I TH tend not to write much code in these entities. That's interesting, any pointer/link for this specific tool? TH I personally think the form schema is much more about the view than the TH model. Sure, however I believe the issue I was raising is orthogonal to this one. Regardless how tight or loosely the form schema is bound to the model, the authorization for a view in Repoze.bfg can effectively be only True or False, which is simple and nice, but sometimes doesn't fit what you need to do. Let's make an example. You have a web application for sharing drawings, you can upload drawings and for each drawing decide which other users you want to share that drawing with. If you share a drawing with another person, that other person can perform the same operations as you on it, like tagging it or removing it. Now let's say that you have views that act on collections of drawings, like you could have a view for handling an HTTP request for tagging a certain group of drawings or deleting them. The HTTP request for those views would typically have a parameter holding a list for drawing IDs to act on. How do you define the permission on those views? With a model-based permissions system, you would simply make the view public and let the model raise Unauthorized if you attempt to do something on a drawing you don't have access too. However with a view-based permission system you need to use some other pattern, and I'm not sure what would be best. Cheers, Free ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Model-based vs. view-based security
Hi Chris, |--== On Wed, 28 Jul 2010 12:38:30 -0400, Chris McDonough chr...@plope.com said: CM Thanks for asking this question, by the way, I have added it (and a CM variation on my answer) to the design defense documentation that is CM present in BFG: CM http://lists.repoze.org/pipermail/repoze-checkins/2010-July/009583.html CM (The rendered version, which doesn't yet include the above addition is CM available at http://docs.repoze.org/bfg/1.3/designdefense.html). That's great to have it there, I hope others will benefit from that reading. As a side node, I really appreciate the documentation effort in Repoze.bfg. Cheers, Free ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Model-based vs. view-based security
Hi, 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 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? 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: 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
