AW: AW: [Zope3-dev] skin support for xmlrpc
Hi Stephan Cc: 'Philipp von Weitershausen'; [EMAIL PROTECTED]; 'Christian Zagrodnick'; zope3-dev@zope.org Betreff: Re: AW: [Zope3-dev] skin support for xmlrpc [...] Since the skin directive is gone layer also support the skinning concept. But the main reason of layers is still offering a security namespace. I disagree. I have *never* thought of it as a security namespace. I think of it as a *user interface* functionality namespace. Doens't matter if you thougt about of it or not. But it is ;-) Skins are a base concept for security if it comes to rewrite rules in Apache. The usage of ++skin++A, ++skin++B let us map domains to request layers. And if we do this right, it let use enable skin A for applicaiton A and restrict using skin A on applicaiton B. Skins e.g. layers which views are registered for are a security layer. The neat thing about skins is that different skins can provide different HTML. But thats the nature of a skin and has nothing to do why the views support a layer attribute. Since we use PageTemplate file in views it let us think that layers are there for change the template or since z3c.pagelets it let us change the layout at all on a view base. But this is just a neat sideeffect of the layer concept. btw, this is also true for z3c.form. The layer attribute let us register a specific IWidget with different permission in one skin then in another skin. It also let us register another template for both skin. this are tow different concepts. That's the reason why I implemented z3c.pagelet. This package let us separate the security layer used for views and the UI layer used for templates. Then both registration concept are based on the layer attribute. [...] 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? The solution is pretty straight forward using a pluggable traverser. After all, pluggable traversers were designed to be maximally flexible and to allow all possibilities, which includes simulating skins, if you want. I don't say it's not possible to secure XML-RPC views with a additional concept e.g. z3c.traverser. Right now we can't take care on security wihtout any a additional concept for XML-RPC views. Layers are the missing feature. That's just bad. Because the available permission attribte sugests to secure them. The real issue here is well known and is called backdoor. Secure views is also hugh and well known problem in the AJAX world which the missing layer in XML-RPC view belongs to. this is also true for JSON views which are based on the XML-RPC implementation. Probably I don't speak about the same use case like Christian had if he started this tread. I just say that security requires a request layer in XML-RPC views. Remember, all what I saying is a problem if it comes to the virtual host supported by the Apache rewrite or proxy usage. Then a XML-RPC without a layer will become available in the wrong domain e.g. in every domain. btw, a z3c.traverser whould have to check for a specific skin in it's request for apply another layer which enables the XML-RPC view. Without a skin layer it's not possible that the traverse acts as a XML-RPC view enabler because the traverser doesn't know if you are calling skin A or skin B. You can say that the traverser is only available on skin A, but then again, you need a layer/skin for that. Regards Roger Ineichen 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/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: AW: [Zope3-dev] skin support for xmlrpc
On Monday 27 August 2007 23:05, Roger Ineichen wrote: Are you all sure you understand the need of a layer in every kind of request? It's about permission registration and not skinning. If it is not about skinning, it should not be done with layers. What I think Christian is trying to do is to create different *namespaces* for an external API. I think that pluggable traversers or a custom namespace (maybe ++ns++name) would be a much less confusing solution. Since the skin directive is gone layer also support the skinning concept. But the main reason of layers is still offering a security namespace. I disagree. I have *never* thought of it as a security namespace. I think of it as a *user interface* functionality 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. Have we ever used layers in this way? Can you give me an example or use case? The more I think about it, the more I think you are wrong. ;-) If you cannot access an action with certain credentials, then you are denied access to the API call. Having different semantics based on credentials for a given API call is a bad idea. You are better served having two functional namespaces. I think a pluggable traverser plugin best implements such a namespace for XML-RPC. 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? The solution is pretty straight forward using a pluggable traverser. After all, pluggable traversers were designed to be maximally flexible and to allow all possibilities, which includes simulating skins, if you want. 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
AW: [Zope3-dev] skin support for xmlrpc
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 Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] skin support for xmlrpc
Cc: zope3-dev zope3-dev Betreff: [Zope3-dev] skin support for xmlrpc hi christian, it seems like your recent changes to support skins in xmlrpc views introduced some troubles. we spent several hours to debug not working xmlrpc views and finally found that nailing the zope.traversing egg to 3.4.x resolved the troubles. while looking at your changes we were wondering why you want to support skins in xmlrpc views? for me, a xmlrpc call is a remote procedure call and has to do nothing with skins. it's not yellow, pink or orange and has no templates associated. can you explain your use-case for this? Jodok, a skin e.g. a layer in a view, even XML-RPC is a security thing not a layout thing. Every traversable adapter needs it's own posibility to register security for it. This is only possible if we have the request available in the discriminator. It's also needed if you setup tow different projects on one server and like to register a XML-RPC view for e.g. ISite in one project and not for the ISite in the other project. If this both sites using a own layer, it's possible ot register the XML-RPC view only for one project. The other option doing this wihtout having a layer in the XML-RPC directive is to use the baseregistry. But why does this break soemthing? Was the initial request interface the BrowserRequest and now it uses by default the IDefaultBrowserLayer? This whould be bad. Using the IBrowserRequest as default layer whould be the best choice. It whouldn't break anything and allows to register views only with your specific request/interface. Regards Roger Ineichen _ END OF MESSAGE thanks jodok -- Explicit is better than implicit. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
