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
Re: [Repoze-dev] Model-based vs. view-based security
Am 29.07.2010, 10:25 Uhr, schrieb Free Ekanayaka free.ekanay...@gmail.com: 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. Form inference via schema adapter should be possible but I think there is consensus that interfaces that are schemas can cause more problems than they solve. Convenience versus overhead and confusion. 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. In those cases you are free to add more to it such as, as Chris said, security proxies. Making this standard adds a lot of overhead to cases where it is totally irrelevant. NB. BFG's openness with regard to storage means you have to think about non-ZODB environments if you wish to have object-level security. 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. I would think you would need to add something to your application to handle this (something akin to workflow) but I don't see why you can't stick with security. BFG provides all the necessary hooks for fine-grained security. Regarding Maartijn's discussion of configuration close to the objects. Having grown up with Zope 2 I'm not keen to see declareProtected(), etc. return for this even if you have decorators. Much better, in my view, to have adapters and views implement behaviour and secure these. I guess the only thing that's missing is security aware form generation, ie. the ability to lock down parts of the form. With a form generation library such as deform this can be done at the view level, although it's not ideal. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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 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? I am using enterprise architect. http://www.sparxsystems.com.au/ It can actually reverse engineer and generate python, but its code lifecycle tools really need some customising (in tool) for python. EE will also reverse engineer (with full roundtrip) from RDBMS, WSDL, C, Java, C++, . . So I am using a code generation tool that I have written over the last few years (for another customer, so at the moment I can't release it, but am planning to rewrite it to target both argouml and enterprise architect). I am currently able to generate from the xmi files the following storm schema from a reverse engineered rdbms. zope3 model and schema bobo view/routes/subroutes (and some viewlet equivalents - basic zope component multi adapter lookup of view fragments, based on context, request, user, view) bfg models formish form schema. postresql DDL. code generation templates are based on dtml. Conceptually its inspired by archgenxml but I found it too difficult to repurpose archgenxml for completely different purposes. Rgds T ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
