Re: skin support for xmlrpc
Christian Zagrodnick <[email protected]>
| Newsgroups | gmane.comp.web.zope.zope3 |
|---|---|
| Message-ID | <[email protected]> |
On 2007-09-15 17:35:20 +0200, "Roger Ineichen" <[email protected]> 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