This was a pretty lame response. After re-looking at it, I remember some other specifics about why I didn't choose zope.security:
- Lots of its code is to allow you to create "untrusted" code, and it creates proxies for this purpose. repoze.bfg has no concept of untrusted code. - Its security policies mak assumptions about "interactions" and "participants", which are zope publisher concepts (misguided ones, IMO) that do not exist in repoze.bfg. All that said, it should be trivial to create a *new* repoze.bfg security policy that used hooked up principals to permissions in such a way that it might emulate the concepts in Zope security that folks are used to (essentially replacing the ACL model). Note that permissions in bfg don't need to be predefined currently as in Zope (you don't need <zope:permission....>), so I'm not sure there's much of anything in zope.security *itself* that's useful to bfg. There may be stuff in zope.app.security that's more appropriate, but there's no way bfg itself can depend on that package, as it pulls in "the world" (even ZODB!). - C On Aug 28, 2008, at 9:39 AM, Chris McDonough wrote: > > On Aug 26, 2008, at 9:01 AM, Malthe Borch wrote: > >> David Pratt, Tim Terlegård and I had a brief conversation about the >> decision to implement a new security policy in repoze.bfg based on >> ACL. >> >> Worries: >> >> 1) This does away with ``zope.security``, which was the de-facto >> security model for Zope and one most developers are intimately >> familiar with. Is it possible to support a setup where this security >> model would be used instead of the new ACL-based policy? > > I'm not certain. zope.security is pretty complicated (IMO, > needlessly) and I'm not personally particularly hot on roles. But I > don't think it's impossible. > >> >> 2) The syntax for the ACL policy is quite crude in my view; it uses >> tuple-notation and strings where I would've considered a scheme that >> was less error-prone (on both accounts: a tuple notation is often >> difficult because the ordering is so random, and strings could >> lead to >> hard-to-catch typos). > > I haven't added any API for setting it, as I couldn't think of a way > that didn't involve passing the three arguments to a function, which > turns into the same thing, although I suppose it could do error > checking. > > - C > > _______________________________________________ > Repoze-dev mailing list > Repoze-dev@lists.repoze.org > http://lists.repoze.org/listinfo/repoze-dev > _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
