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++) 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
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. 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
Re: [Zope3-dev] skin support for xmlrpc
On 27.08.2007, at 22:11, Christian Theune wrote: Hi, Am Freitag, den 24.08.2007, 07:55 +0200 schrieb Jodok Batlogg: 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? Let me try to wrap some of the things up here. When we drafted this change, we followed the idea of the refactoring for skins as they are now (switching from a separate skin/layer implementation to the current marker interfaces on requests) which was very technically focused. So were we. I see that we're misusing the ++skin++ traversal namespace and should introduce another namespace instead. Our mistake. We introduced the change as we thought it to be straightforward and a logical extension. As stated above we overlooked the simple solution of another traverser. We did not anticipate it to be such a strong problem otherwise we'd created a separate proposal instead of just going forward. Zagy posted a reply to your question for a use case on that thread in the checkins list [1] but unfortunately that thread died off with this message and nobody returned to it. Let me propose a change: 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. I do have the feeling that differentiating the XML/RPC-API based on specifics of the request are of value (it certainly is for us) as are skins. perfectly fine. i prefer the separate package :) jodok If we can decide to ship a new traversal namespace for zope.publisher then we'd be happy to do that. Otherwise we'll just go on with a separate package. Hooray for the CA. Christian [1] ... http://mail.zope.org/pipermail/checkins/2007-August/ 012638.html ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists% 40lovelysystems.com -- "Simple is better than complex." -- 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 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] skin support for xmlrpc
Hi, Am Freitag, den 24.08.2007, 07:55 +0200 schrieb Jodok Batlogg: > 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? Let me try to wrap some of the things up here. When we drafted this change, we followed the idea of the refactoring for skins as they are now (switching from a separate skin/layer implementation to the current marker interfaces on requests) which was very technically focused. So were we. I see that we're misusing the ++skin++ traversal namespace and should introduce another namespace instead. Our mistake. We introduced the change as we thought it to be straightforward and a logical extension. As stated above we overlooked the simple solution of another traverser. We did not anticipate it to be such a strong problem otherwise we'd created a separate proposal instead of just going forward. Zagy posted a reply to your question for a use case on that thread in the checkins list [1] but unfortunately that thread died off with this message and nobody returned to it. Let me propose a change: 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. I do have the feeling that differentiating the XML/RPC-API based on specifics of the request are of value (it certainly is for us) as are skins. If we can decide to ship a new traversal namespace for zope.publisher then we'd be happy to do that. Otherwise we'll just go on with a separate package. Hooray for the CA. Christian [1] ... http://mail.zope.org/pipermail/checkins/2007-August/012638.html ___ 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
[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? 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 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
