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