[Zope3-dev] Re: skin support for xmlrpc

Christian Zagrodnick cz at gocept.com
Tue Sep 18 02:33:53 EDT 2007


On 2007-09-15 17:35:20 +0200, "Roger Ineichen" <dev at projekt01.ch> said:

>>> 
>> 
>> Ok, then I suggest:
>> 
>> * Provide an IRequestType interface in zope.publisher
>> * Provide an ++api++ traverser in zope.traversing which does
>> `getUtility(IRequestType, *name*)`.
>> * define class IBrowserSkinType(IRequestType)
>> * Leave ++skin++ for IBrowserSkinType or just make it the
>> same as ++api++
>> * Keep layer="" on <xmlrpc:view>, <browser:page> etc.
>> 
>> Comments?
> 
> 
> If I understand the concept correct. This is a builtin backdoor.
> 
> Doesn't this allow to bypass the Apache rewrite rule?
> With: http://www.foobar.com/++api++xmlrpc/doSomething
> 
> If the rewrite rule in Apache is:
> RewriteRule (/?.*)
> http://localhost:8080/++skin++OnlyHere/++vh++https:www.foobar.com:443/++$1
> [P,L]

I suppose you're right. Even though I wonder if you couldn't also say

http://www.foobar.com/++skin++GetMeThere/doSomething

to get another Browser-Skin. But you're right, that you must never get 
a XML-RPC method with an BrowserRequest.

> 
> Or does the ++api++ namespace recognize the skin?
> Which means the url rewritten url is.
> With: http://www.foobar.com/++skin++OnlyHere/++api++xmlrpc/doSomething
> 
> But then, do we need to regsiter the ++api++ for each
> layer? I guess this is not what you are asking for. right?

No, it's quite the same as with skins, i.e. You can concider one Layer 
as a Skin or aggregate multiple Layers into one skin.

> 
> My main issue on this thread is allways the same:
> Skins are a security layer. And don't bypass them,
> then this let us use views which we don't like to
> provide in a layer/skin.

Right. But it's not *really* about security. For a browser you usually 
define how a web page looks like and thereby of course define what's 
possible and what not. For XML-RPC you define the API. But ultimately 
this is not security. Security is achieved by the security proxy. You 
must take  care that an unprivileged user cannot access a method which 
he should is allowed to. And you do that via the security engine.

-- 
Christian Zagrodnick

gocept gmbh & co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891





More information about the Zope3-dev mailing list