I want Zope 2.9 to use Zope 3's security architecture.
I very much want Zope 2.9 to use Zope 3's security architecture. Zope 3's security architecture is far more robust, but it is different in some significant ways: - It protects names not values. This means that you protect how you access things, not the things themselves. - It doesn't provide key-bases access control for mapping objects. If you can get any key, you can get all keys. This is less powerful that Zope 2's security system, but this is power we haven't needed for Zope 3 and I suggest we don't really need it for Zope 2. - Non-basic values passed from trusted code to untrusted code are security proxied and thus protected. This means that the security framework has a much greater reach than in Zope 2, Even trusted code is subject to the security system in many cases. This can be a good thing or a bad thing, depending on your point of view. :) - The Zope 3 security system is much more pluggable. This means that it is much easier to provide alternate security policies to meet special needs to or exclude unneeded features. For more information on the security system, see: http://svn.zope.org/Zope3/trunk/src/zope/security/untrustedinterpreter.txt?v... http://svn.zope.org/Zope3/trunk/src/zope/security/README.txt?view=markup http://svn.zope.org/Zope3/trunk/src/zope/app/securitypolicy/zopepolicy.txt?v... http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ProgrammerT... I see 2 main challenges: - supporting implicit acquisition - Backward incompatibilities: o No support for key-based access control o Trusted code will be subject to security restrictions in cases in which it isn't now. I think there will be a number of significant benefits, including: - Greater security - Less complexity - Less risk with new Python versions - Narrower gap between Zope 2 and Zope 3. This will be a fairly large job. I won't have time to work on it before this Fall. I could certianly use some help. :) Are there any objections? Suggestions? Questions? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Wed, Apr 06, 2005 at 08:33:39AM -0400, Jim Fulton wrote:
I very much want Zope 2.9 to use Zope 3's security architecture. Zope 3's security architecture is far more robust, but it is different in some significant ways:
(snip) Will this all be "under the hood"? i.e. will Products have to be rewritten for 2.9? i.e. will I still write: security.declareProtected(SomePermission, 'foo') def foo(self): ...
I see 2 main challenges:
- supporting implicit acquisition
- Backward incompatibilities:
o No support for key-based access control
Don't know what that is. -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote:
On Wed, Apr 06, 2005 at 08:33:39AM -0400, Jim Fulton wrote:
I very much want Zope 2.9 to use Zope 3's security architecture. Zope 3's security architecture is far more robust, but it is different in some significant ways:
(snip)
Will this all be "under the hood"? i.e. will Products have to be rewritten for 2.9?
I don't know. I expect that most products would not have to be rewritten. I expect that *some* proucts would. (e.g. products that depend on key-based access control.)
i.e. will I still write:
security.declareProtected(SomePermission, 'foo') def foo(self): ...
That will work, and I don't see a need to deprecate it. Eventually, though, I expect products to migrate to ZCML-based security declarations. ...
o No support for key-based access control
Don't know what that is.
It was/is possible to control access to mapping items based on item values (e.g. key values). Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Wed, Apr 06, 2005 at 12:49:19PM -0400, Jim Fulton wrote:
o No support for key-based access control
Don't know what that is.
It was/is possible to control access to mapping items based on item values (e.g. key values).
OK... I've never used this AFAIK. Anybody know if it's a widely used feature? -- Paul Winkler http://www.slinkp.com
On Wed, Apr 06, 2005 at 12:49:19PM -0400, Jim Fulton wrote: | >i.e. will I still write: | > | > security.declareProtected(SomePermission, 'foo') | > def foo(self): | > ... | | That will work, and I don't see a need to deprecate it. | Eventually, though, I expect products to migrate to | ZCML-based security declarations. BTW, Five already allows ZCML-based security declarations, to the extent supported by Zope 2. You can't protect assigning to instance attributes by a permission until we move to Zope 3 security implementation. | It was/is possible to control access to mapping items | based on item values (e.g. key values). Is this related in any way to having a dictionary or callable in __allow_access_to_unprotected_subobjects__? I ask because we just started abusing this one *wink*. -- Sidnei da Silva <sidnei@awkly.org> http://awkly.org - dreamcatching :: making your dreams come true http://www.enfoldsystems.com http://plone.org/about/team#dreamcatcher <jumpy> we are the knights who say INT! SHORT! and UNSIGGGGGGGGGGGGGGGGNNNNNNNNNNNEDDDDDDDDDDDDD LONNNNNNNNNGGGGGG!
Sidnei da Silva wrote: ...
Is this related in any way to having a dictionary or callable in __allow_access_to_unprotected_subobjects__?
I ask because we just started abusing this one *wink*.
I believe so. I don't remember the details. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 7 Apr 2005 02:49 am, Jim Fulton wrote:
Paul Winkler wrote:
i.e. will I still write:
security.declareProtected(SomePermission, 'foo') def foo(self): ...
That will work, and I don't see a need to deprecate it. Eventually, though, I expect products to migrate to ZCML-based security declarations.
Is this a general trend for Zope 2? I'd rather see Zope 2 kinda avoid ZCML if possible. It's just one of those personal preference things, I suppose, but I know I'm not the only one who isn't that enamored of the ZCML approach. I actually like having the declarations all in the python code like it is in Zope 2. I'd like to see the declarative style that Zope 2 move to using decorators. I was sitting in a presentation at PyCon talking about MetaClasses, and I finally *got* them. I realised that the security declarations in Zope 2 are a perfect fit for metaclasses and decorators. If only I had the time to actually implement this dream ;) Note that this all comes from the perspective of someone whose only exposure to Zope 3 has been through two sprints. I've not actually tried to develop any sort of application using it. My day job is very firmly fixed in Zope 2, and isn't likely to change for a long time. So I'm definitely speaking from ignorance of real-world application development in Zope 3. Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCVIIirGisBEHG6TARAowSAKCGSgaIkZeLJfg1NFlnzKdhOZDa3QCePu30 f5MPM1sUwbBEVykehbyNH7o= =v736 -----END PGP SIGNATURE-----
Richard Jones wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 7 Apr 2005 02:49 am, Jim Fulton wrote:
Paul Winkler wrote:
i.e. will I still write:
security.declareProtected(SomePermission, 'foo') def foo(self): ...
That will work, and I don't see a need to deprecate it. Eventually, though, I expect products to migrate to ZCML-based security declarations.
Is this a general trend for Zope 2? I'd rather see Zope 2 kinda avoid ZCML if possible. It's just one of those personal preference things, I suppose, but I know I'm not the only one who isn't that enamored of the ZCML approach. I actually like having the declarations all in the python code like it is in Zope 2.
As I said, I don't see a need to deprecate the Zope 2 style in this case. I think that most people who've tried it find they prefer having the security declarations separate. This is more compelling for Zope 3 code, which tends to have less Zope-isms to begin with,
I'd like to see the declarative style that Zope 2 move to using decorators. I was sitting in a presentation at PyCon talking about MetaClasses, and I finally *got* them. I realised that the security declarations in Zope 2 are a perfect fit for metaclasses and decorators. If only I had the time to actually implement this dream ;)
I don't see any use for metaclasses in making security declarations. For me, metaclasses (like proxies) are deep and powerful magic that should only be used when they are realy needed.
Note that this all comes from the perspective of someone whose only exposure to Zope 3 has been through two sprints. I've not actually tried to develop any sort of application using it. My day job is very firmly fixed in Zope 2, and isn't likely to change for a long time. So I'm definitely speaking from ignorance of real-world application development in Zope 3.
Fair enough. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Richard Jones wrote: [snip]
Is this a general trend for Zope 2? I'd rather see Zope 2 kinda avoid ZCML if possible.
The Five integration philosophy at least, is that it makes use of ZCML *possible* in Zope 2, but not at all mandatory. Five tries to mess with the innards of Zope 2 as much as possible, because it's complicated enough to add Zope 3 to Zope 2 already; we don't want to worry about changing Zope 2 (or Zope 3). Zope 2.9 has traditionally been seen as a version of Zope 2 where the innards *will* change to integrate deeper into Zope 3. Five's philosophy makes it impossible to do certain kinds of Zope 3 integration with Zope 2, such as security in particular. Though in fact I'm surprised how much *is* already possible given the limitations Five has; I think that's an interesting finding. Anyway, you might want to give Five a spin one day. Perhaps you'll change your mind about ZCML. Five introduces Zope 3 concepts more gradually to the Zope 2 hacker than Zope 3 itself, so it may be less overwhelming; Zope 3 certainly sometimes tends to overwhelm me, still. Regards, Martijn
Richard Jones wrote:
Is this a general trend for Zope 2? I'd rather see Zope 2 kinda avoid ZCML if possible. It's just one of those personal preference things, I suppose, but I know I'm not the only one who isn't that enamored of the ZCML approach. I actually like having the declarations all in the python code like it is in Zope 2.
Am I right in thinking that the XML part of ZCML is layered over python functionality underneath? If so, how hard would it be to provide an alternative to the baroque XML? - the bit of ZCML I don't like ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Richard Jones wrote:
Is this a general trend for Zope 2? I'd rather see Zope 2 kinda avoid ZCML if possible. It's just one of those personal preference things, I suppose, but I know I'm not the only one who isn't that enamored of the ZCML approach. I actually like having the declarations all in the python code like it is in Zope 2.
Am I right in thinking that the XML part of ZCML is layered over python functionality underneath? If so, how hard would it be to provide an alternative to the baroque XML? - the bit of ZCML I don't like ;-)
It's is theoretically possible, but not really worth the effort. I'll note that ZCML has gotten progressively simpler over the years. It continues to get simpler. For example, now that we we can say more about adapters in Python, a typical adapter registration looks like: <adapter factory=".Myfactory" /> Also, for various reasons, ZCML took on implementation capabilities. We're looking at ways to move that implementation capability back into Python, where it belongs, which will make page definition easier. I expect that page definitions in the future will look more like: <page name="foo.html" class=".FooView.html" permission="zope.View" /> Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Richard Jones wrote:
Is this a general trend for Zope 2? I'd rather see Zope 2 kinda avoid ZCML if possible. It's just one of those personal preference things, I suppose, but I know I'm not the only one who isn't that enamored of the ZCML approach.
ZCML started out for me (and as an experinced zope2 programmer I guess the experience may not be that unusual) as "ooh, my, lots to learn, why is it that complex"? Then it becames "oh, it's a consistent way of doing all those thinks that weren't very pythonic, like defining page templates", and then finally I grasped it with "ah, it's really the best parts of aspect orientation; you make all these separate modules, and you tie them together with ZCML!" Like XML or not, the approach of moving this type of meta-information to ZCML rocks. You know the feeling when a third party product has the wrong permission or no permission at all on something? What are you gonna do? Subclass: Lots of work. Patch: You gotta keep it updated. With ZCML, you override it. TADA!
Lennart Regebro wrote:
You know the feeling when a third party product has the wrong permission or no permission at all on something? What are you gonna do? Subclass: Lots of work. Patch: You gotta keep it updated. With ZCML, you override it. TADA!
Yes, this is all stuff I know and love about Z3 ;-) When I last saw ZCML, it was horrible though. I don't mind XML, just not if it lots of pointless typing... Jim suggests that ZCML has got better, I hope so, in which case I won't have to write an alternative that uses the same underlying infrastructure :-D cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Lennart Regebro wrote:
You know the feeling when a third party product has the wrong permission or no permission at all on something? What are you gonna do? Subclass: Lots of work. Patch: You gotta keep it updated. With ZCML, you override it. TADA!
Yes, this is all stuff I know and love about Z3 ;-) When I last saw ZCML, it was horrible though. I don't mind XML, just not if it lots of pointless typing...
Jim suggests that ZCML has got better, I hope so, in which case I won't have to write an alternative that uses the same underlying infrastructure :-D
Since ZML is XML, creating a less verbose language may be easier to accomplish by actually *using* the XML infrastructure, and translating your language to ZCML. Anyway, while I have my criticisms of ZCML, too much typing is really not very important in my list. You can get it somewhat shorter, I'm sure, but not *that* much shorter. I'd worry more about the reading part than the writing. Regards, Martijn
On Apr 8, 2005 12:54 PM, Martijn Faassen <faassen@infrae.com> wrote:
Chris Withers wrote:
Lennart Regebro wrote:
You know the feeling when a third party product has the wrong permission or no permission at all on something? What are you gonna do? Subclass: Lots of work. Patch: You gotta keep it updated. With ZCML, you override it. TADA!
Yes, this is all stuff I know and love about Z3 ;-) When I last saw ZCML, it was horrible though. I don't mind XML, just not if it lots of pointless typing...
Jim suggests that ZCML has got better, I hope so, in which case I won't have to write an alternative that uses the same underlying infrastructure :-D
Since ZML is XML, creating a less verbose language may be easier to accomplish by actually *using* the XML infrastructure, and translating your language to ZCML.
Anyway, while I have my criticisms of ZCML, too much typing is really not very important in my list. You can get it somewhat shorter, I'm sure, but not *that* much shorter. I'd worry more about the reading part than the writing.
Yeah, I mean: <something:something foo="bar" frotz="fnyppel"> <fingal:ohlsson bitbucket="buccaneer" /> </something:something> Is not significantly shorter than: something/something: foo=bar frotz=fnyppel fingal/ohlsson: bitbucket=buccaneer Which would be really a minimal/shortest way to write it. For me, the main drawback with ZCML is that WingIDE doesn't to auto completion on it. ;) An ZCML editor that automatically popped up a list of the supported keywords for every statement would be really nice. :-p A benefit of using an XML format is that many editors will happily both do syntax high-lighting, some sort of auto-indentation, and automatic commenting/uncommenting. A non-standard syntax wouldn't do that. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Lennart Regebro wrote:
On Apr 8, 2005 12:54 PM, Martijn Faassen <faassen@infrae.com> wrote:
...
A benefit of using an XML format is that many editors will happily both do syntax high-lighting, some sort of auto-indentation, and automatic commenting/uncommenting. A non-standard syntax wouldn't do that.
Speaking of which, a nice little project for someone would be to write a generator to generate RelaxNG schemas from ZCML meta configuration. Then XML editors could provide more help with the editing, possibly including hings like autocompletion. This should be a realtively easy task in that apidoc already has code for extracting documentation from meta configuration. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Friday 08 April 2005 07:34, Lennart Regebro wrote:
For me, the main drawback with ZCML is that WingIDE doesn't to auto completion on it. ;) An ZCML editor that automatically popped up a list of the supported keywords for every statement would be really nice. :-p:
Yeah, I talked to Stephan and John about that already. Using Wing's new plugin architecture, it should be possible to insert such functionality. Another good application for the plugin system would be the recognition of interfaces by showing the interface documentation of a class implementing a certain interface. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
On Apr 8, 2005 3:09 PM, Stephan Richter <srichter@cosmos.phy.tufts.edu> wrote:
On Friday 08 April 2005 07:34, Lennart Regebro wrote:
For me, the main drawback with ZCML is that WingIDE doesn't to auto completion on it. ;) An ZCML editor that automatically popped up a list of the supported keywords for every statement would be really nice. :-p:
Yeah, I talked to Stephan and John about that already. Using Wing's new plugin architecture, it should be possible to insert such functionality. Another good application for the plugin system would be the recognition of interfaces by showing the interface documentation of a class implementing a certain interface.
Cool, that's good news. I won't have time to do it for the forseeable future though... -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Lennart Regebro wrote: [snip]
For me, the main drawback with ZCML is that WingIDE doesn't to auto completion on it. ;) An ZCML editor that automatically popped up a list of the supported keywords for every statement would be really nice. :-p
Actually emacs + nxml + the Relax NG schema (unfortunately out of date; it should be autogenerated from the code) for ZCML does that.
A benefit of using an XML format is that many editors will happily both do syntax high-lighting, some sort of auto-indentation, and automatic commenting/uncommenting. A non-standard syntax wouldn't do that.
Yup, and if you use some XML editor (or an XML editor extension for your favorite editor) it can do quite sophisticated schema-driven stuff. Regards, Martijn
Martijn Faassen wrote:
Anyway, while I have my criticisms of ZCML, too much typing is really not very important in my list. You can get it somewhat shorter, I'm sure, but not *that* much shorter. I'd worry more about the reading part than the writing.
More typing = more reading in my books, so I guess we're in agreement ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Friday 08 April 2005 03:24, Chris Withers wrote:
Yes, this is all stuff I know and love about Z3 ;-);-) When I last saw ZCML, it was horrible though. I don't mind XML, just not if it lots of pointless typing...
Can you be more specific? I think ZCML is very compact. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Stephan Richter wrote:
Can you be more specific? I think ZCML is very compact.
Well, I'm hoping to take a proper look at the latest Z3 "some time soon", so I'll let you know after that and shut up on the subject in the meantime ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Jim Fulton wrote at 2005-4-6 08:33 -0400:
I very much want Zope 2.9 to use Zope 3's security architecture. Zope 3's security architecture is far more robust, but it is different in some significant ways:
Even small modifications to the security machinery tend to end up in lots of problems. The latest prominent example: the changes introduced with Zope 2.7.3: It took two releases (until 2.7.5) and more than 6 months (at least in my memory) before everything worked again as it should... Hopefully, such a major change will not require 4, 5, 6 minor releases and years for stabilazation... -- Dieter
Dieter Maurer wrote:
Jim Fulton wrote at 2005-4-6 08:33 -0400:
I very much want Zope 2.9 to use Zope 3's security architecture. Zope 3's security architecture is far more robust, but it is different in some significant ways:
Even small modifications to the security machinery tend to end up in lots of problems.
The latest prominent example: the changes introduced with Zope 2.7.3: It took two releases (until 2.7.5) and more than 6 months (at least in my memory) before everything worked again as it should...
Hopefully, such a major change will not require 4, 5, 6 minor releases and years for stabilazation...
Hopefully not. It depends on whether people choose to test their application during the beta cycle or during the release cycle. This will be a *big* change. Possibly, this will be bigger than the change from 2.7 to 2.8. I do think it will provide significant benefits that justify the pain. Of course, when we try it, we may find it is too painful and we'll have to reconsider. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
--On Mittwoch, 6. April 2005 21:59 Uhr +0200 Dieter Maurer <dieter@handshake.de> wrote:
Jim Fulton wrote at 2005-4-6 08:33 -0400:
I very much want Zope 2.9 to use Zope 3's security architecture. Zope 3's security architecture is far more robust, but it is different in some significant ways:
Even small modifications to the security machinery tend to end up in lots of problems.
The latest prominent example: the changes introduced with Zope 2.7.3: It took two releases (until 2.7.5) and more than 6 months (at least in my memory) before everything worked again as it should...
I don't know exactly to which changes do you refer. Either little people that this problem or people did not use these releases or people did not test enough or people did not contribute enough to fix this bug in time *wink*. -aj
On Apr 7, 2005, at 6:50, Andreas Jung wrote:
Even small modifications to the security machinery tend to end up in lots of problems.
The latest prominent example: the changes introduced with Zope 2.7.3: It took two releases (until 2.7.5) and more than 6 months (at least in my memory) before everything worked again as it should...
I don't know exactly to which changes do you refer. Either little people that this problem or people did not use these releases or people did not test enough or people did not contribute enough to fix this bug in time *wink*.
This is probably in reference to some overeager security checks that caused login boxes in unexpected places. Jim and Tres fixed that for 2.7.5. I thought that problem was older than 2.7.3, though. jens
participants (11)
-
Andreas Jung -
Chris Withers -
Dieter Maurer -
Jens Vagelpohl -
Jim Fulton -
Lennart Regebro -
Martijn Faassen -
Paul Winkler -
Richard Jones -
Sidnei da Silva -
Stephan Richter