[Zope3-dev] Re: skin support for xmlrpc
On 2007-09-14 18:54:01 +0200, Fred Drake [EMAIL PROTECTED] said: On 9/14/07, Roger Ineichen [EMAIL PROTECTED] wrote: If you register views for a base request type, you probably will open a backdor in other projects. Because I'm not advocating registering views for the base request types generally, but only the way to specify in the URL what the request type is. Because sometimes we really do want completely separate sets of XML-RPC (or whatever) interfaces. Ok, then I suggest: * Provide an IRequestType interface in zope.publisher * Provide an ++api++ traverser in zope.traversing which does `getUtility(IRequestType, *name*)`. * define class IBrowserSkinType(IRequestType) * Leave ++skin++ for IBrowserSkinType or just make it the same as ++api++ * Keep layer= on xmlrpc:view, browser:page etc. Comments? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.testbrowser packaging
I have a small issue with zope.testbrowser packaging I'd like to get some input on. If I were to have started the project today, it would likely have been zc.testbrowser, which would have no Zope 3 dependencies (or functionality) and zc.testbrowser.zope, which would have, and depended on zc.testbrowser. Well, that didn't happen, but there are parallels to the current situation that might be informative. There is a configuration bug in testbrowser that means that unless you include the test extra, you won't get the Zope 3 dependencies. I suspect most people either include that extra, or accidentally include the dependencies through other packages. I have two ideas for fixing this: 1) introduce a zope extra that everyone will have to use (basically just rename test to zope; 2) take a lesson from the fictional zc.testbrowser and introduce another package (zope.testbrowser.zope) that contains the Zope 3 bits and depends on zope.testbrowser. I think I prefer the second, despite it's strange appearance. Thoughts? -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.testbrowser packaging
Hi Benji. I don't like the first option. I am already using a zope extras to group packages for other reasons and don't really want to mix this with the test extra. I am trying to use extras as much as possible opposed to listing reams of packages in buildout.cfg to keep it cleaner and simpler. I don't mind the strange name to be honest, the namespaces are informative. Many thanks. Regards, David Benji York wrote: I have a small issue with zope.testbrowser packaging I'd like to get some input on. If I were to have started the project today, it would likely have been zc.testbrowser, which would have no Zope 3 dependencies (or functionality) and zc.testbrowser.zope, which would have, and depended on zc.testbrowser. Well, that didn't happen, but there are parallels to the current situation that might be informative. There is a configuration bug in testbrowser that means that unless you include the test extra, you won't get the Zope 3 dependencies. I suspect most people either include that extra, or accidentally include the dependencies through other packages. I have two ideas for fixing this: 1) introduce a zope extra that everyone will have to use (basically just rename test to zope; 2) take a lesson from the fictional zc.testbrowser and introduce another package (zope.testbrowser.zope) that contains the Zope 3 bits and depends on zope.testbrowser. I think I prefer the second, despite it's strange appearance. Thoughts? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.testbrowser packaging
Benji York wrote: I have a small issue with zope.testbrowser packaging I'd like to get some input on. If I were to have started the project today, it would likely have been zc.testbrowser, which would have no Zope 3 dependencies (or functionality) and zc.testbrowser.zope, which would have, and depended on zc.testbrowser. Well, that didn't happen, but there are parallels to the current situation that might be informative. There is a configuration bug in testbrowser that means that unless you include the test extra, you won't get the Zope 3 dependencies. I suspect most people either include that extra, or accidentally include the dependencies through other packages. I have two ideas for fixing this: 1) introduce a zope extra that everyone will have to use (basically just rename test to zope; 2) take a lesson from the fictional zc.testbrowser and introduce another package (zope.testbrowser.zope) that contains the Zope 3 bits and depends on zope.testbrowser. I think this would be very hard if not impossible to do from a packaging perspective (declaring zope.testbrowser a namespace package *and* have it contain things like README, configure.zcml, etc.). I think I prefer the second, despite it's strange appearance. Thoughts? Let's look at this from the beginning. zope.testbrowser contains a) a reusable, completely Zope-independent test browser b) integration with zope.app.testing.functional, in other words a test browser for testing web applications based on zope.publisher. I think in its current use, zope.testbrowser is *mostly* used as b). When used as a), I don't think anybody is bothered by the fact that it might or might not have more dependencies (other than the inconvenience of having to install more stuff than actually necessary). So here's what I suggest: Factor out a) to a new package 'zc.testbrowser' (or whatever) and make 'zope.testbrowser', the remaining b), depend on zc.testbrowser, zope.app.testing and all that other stuff properly. That way - packaging and nomenclature are straight-forward, - we don't have to break backwards compatibility anywhere, - people who have used 'zope.testbrowser' because of a) until now won't experience any problems, even though we should probably tell them to switch to zc.testbrowser. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: skin support for xmlrpc
Hi Christian Betreff: [Zope3-dev] Re: skin support for xmlrpc On 2007-09-14 18:54:01 +0200, Fred Drake [EMAIL PROTECTED] said: On 9/14/07, Roger Ineichen [EMAIL PROTECTED] wrote: If you register views for a base request type, you probably will open a backdor in other projects. Because I'm not advocating registering views for the base request types generally, but only the way to specify in the URL what the request type is. Because sometimes we really do want completely separate sets of XML-RPC (or whatever) interfaces. Ok, then I suggest: * Provide an IRequestType interface in zope.publisher * Provide an ++api++ traverser in zope.traversing which does `getUtility(IRequestType, *name*)`. * define class IBrowserSkinType(IRequestType) * Leave ++skin++ for IBrowserSkinType or just make it the same as ++api++ * Keep layer= on xmlrpc:view, browser:page etc. Comments? If I understand the concept correct. This is a builtin backdoor. Doesn't this allow to bypass the Apache rewrite rule? With: http://www.foobar.com/++api++xmlrpc/doSomething If the rewrite rule in Apache is: RewriteRule (/?.*) http://localhost:8080/++skin++OnlyHere/++vh++https:www.foobar.com:443/++$1 [P,L] Or does the ++api++ namespace recognize the skin? Which means the url rewritten url is. With: http://www.foobar.com/++skin++OnlyHere/++api++xmlrpc/doSomething But then, do we need to regsiter the ++api++ for each layer? I guess this is not what you are asking for. right? My main issue on this thread is allways the same: Skins are a security layer. And don't bypass them, then this let us use views which we don't like to provide in a layer/skin. I really don't understand this thread. Does nobody take care on default traversal APIs? I'm really confused now. Probably I don't see soemthing or understand it not correctly. Do you understand what I mean this this backdoor use case? Or I'm totaly wrong? Regards Roger Ineichen -- Christian Zagrodnick gocept gmbh co. kg . forsterstrasse 29 . 06112 halle/saale www.gocept.com . fon. +49 345 12298894 . fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.testbrowser packaging
On Saturday 15 September 2007 08:48, Benji York wrote: 1) introduce a zope extra that everyone will have to use (basically just rename test to zope; I prefer this solution. I have done this before for z3c.rml, where I put the page template support into a pagetemplate extra declaration. I liked this solution a lot. I would have never considered developing another package for a fairly trivial extension of a few lines. I think eggs have the potential for package proliferation and senseless overhead. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
