Hi all > Cc: Christian Zagrodnick > Betreff: Re: [Zope3-dev] skin support for xmlrpc > > On Monday 27 August 2007 16:11, Christian Theune wrote: > > 1. We revert the change. > > > > 2. We create a new traverser with a different namespace that > > implements > > our intended behaviour. > > > > Two options after that: > > > > 3a. We supply this traverser by default, or > > > > 3b. We ship it in a separate package. > > +1 with option 3b. BTW, you should have a look at > z3c.traverser, which > +allows > you to not use namespaces at all anymore.
eek, I don't like to think about that. No, no, no... just wait, Christian is defently right to add layer for XML-RPC views. Are you all sure you understand the need of a layer in every kind of request? It's about permission registration and not skinning. Since the skin directive is gone layer also support the skinning concept. But the main reason of layers is still offering a security namespace. In short -------- "skin support in xmlrpc" --> No "layer support in xmlrpc" --> Yes it's a security issue! Layers allow us to use different security registrations for the same view in different projects. seccurity issue --------------- Let's say you have a app offering a XML-RPC server shutdown view. You whould do the following: 1. regsiter a public and a private skin 2. register the XML-RPC view to the layer used by the private skin 3. Run Zope at port 8080 blocked form outside by firewall 4. Use Apache rewrite rules and point to the public and private skin e.g. private.foo.com and public.foo.com 5. Use a rewrite rule and point to the private skin restricting access to a internal network or some IP addresses. How whould you restrict access from the public skin to the XML-RPC view without layer support used in step 2? Hm, nobody seeing this let me think that I'm wrong. But I'm pretty sure that I'm right. or not? Regards Roger Ineichen _______________________________________________ Zope3-dev mailing list Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com