Hi Charlie,

|--==> On Thu, 29 Jul 2010 10:45:58 +0200, "Charlie Clark" 
<charlie.cl...@clark-consulting.eu> said:

  CC> Am 29.07.2010, 10:25 Uhr, schrieb Free Ekanayaka  
  CC> <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.

  CC> Form inference via schema adapter should be possible but I think there is 
  CC> consensus that interfaces that are schemas can cause more problems than  
  CC> they solve. Convenience versus overhead and confusion.

Agreed, I'm not thrilled by it either.

  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  
  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.

  CC> In those cases you are free to add more to it such as, as Chris said,  
  CC> security proxies. Making this standard adds a lot of overhead to cases  
  CC> where it is totally irrelevant.

Absolutely. My question was more "is there another way I can think to
the problem, that plays well with plain Repoze.bfg (whose design I like
a lot, btw)?". I also appreciate the fact that, like Zope, Repoze.bfg is
pretty pluggable, so you can add what you need.

  CC> NB. BFG's openness with regard to storage means you have to think about  
  CC> 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.

  CC> I would think you would need to add something to your application to  
  CC> handle this (something akin to workflow) but I don't see why you can't  
  CC> stick with security. BFG provides all the necessary hooks for 
  CC> security.

Introducing something like a workflow might be a good idea, I'll think
more about it, thanks.

  CC> Regarding Maartijn's discussion of configuration close to the objects.  
  CC> Having grown up with Zope 2 I'm not keen to see declareProtected(), etc.  
  CC> return for this even if you have decorators. Much better, in my view, to  
  CC> have adapters and views implement behaviour and secure these.

  CC> I guess the only thing that's missing is security aware form generation,  
  CC> ie. the ability to lock down parts of the form. With a form generation  
  CC> library such as deform this can be done at the view level, although it's  
  CC> not ideal.

Yeah, and you need security-awareness both ways, when you display the
form and when you process it.


Repoze-dev mailing list

Reply via email to