Am 29.07.2010, 10:25 Uhr, schrieb Free Ekanayaka  

> 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  

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 Clark
Managing Director
Clark Consulting & Research
German Office
Helmholtzstr. 20
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
Repoze-dev mailing list

Reply via email to