> Cc: 'Philipp von Weitershausen'; [EMAIL PROTECTED]; 'Christian
> Zagrodnick'; firstname.lastname@example.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
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
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.
> 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 mailing list