[Grok-dev] Re: HTTP PUT and HTTP DELETE security support

[Philipp von Weitershausen]

Martijn Faassen wrote:
> This code makes the assumption that a method '__call__' is always the 
> thing to check. This is true in case of the view,

It's true for all things that end up as published objects of a *browser* 
request. This is what we commonly call a browser page. The interface 
that is mandated here is IBrowserPublisher, it includes __call__.

> but that's not right in case of PUT.

Zope 3's HTTP publication looks up views where name=request.method and 
then calls a method with that same name on that view object.

> Looks like I'll have to introduce my own version of 
> callObject for GrokHTTPPublication that doesn't make this assumption. I 
> hacked around this for now by disabling the whole checker thing altogether.
> 
> BrowserPublication handles GET and POST, where this assumption makes 
> sense. In case of PUT and DELETE, it'll try to call a method called PUT 
> or DELETE on a view registered for IHTTPRequest.

Right.

[snip discussion of various approaches to implementing a PUT view]

I would suggest introducing a grok.REST class:

   class MammothREST(grok.REST):

       def PUT(self):
           pass

       def DELETE(self):
           pass

       def ANY_HTTP_VERB(self):
           pass

Naturally, we'll have to come up with a decent interpretation of the 
GET/POST case. By default, GET/POST are interpreted as browser requests 
and the browser publication looks up a default view ('index') when your 
GETting or POSTing to a resource (/herd/manfred ends up really being 
/herd/manfred/index). Perhaps if there's no such 'index' view, Grok's 
browser publication will fall back to the REST adapter and lookup the 
"GET" view (or "POST view, respectively):

   class Herd(grok.Container):
       pass

   class HerdREST(grok.REST):

       def POST(self, item_name, name='Manfred'):
           self.context[item_name] = mammoth = Mammoth(name)
           self.redirect(self.url(mammoth))

We could also do it the other way around, like you suggest, and look for 
the REST handlers for GET/POST first, before falling back to 'index' 
browser pages.

> It will take a bit of work to make this happen though, as I don't think 
> the zope 3 publisher supports doing this out of the box.

The Zope 3 publisher supports everything out-of-the-box :). That is to 
say that the actual policy is in the publication (what happens when, 
which views to look up, etc.).

> We'll have to 
> to make some code that looks for this Post thing first, and if it's not 
> there, fall back on the normal view behavior. This has some performance 
> implications, however (an extra view lookup).

An extra adapter lookup is not likely going to be a big performance 
killer. Also, let's not optimize prematurely :).

> Comments? Ideas? Eager Zope 3 publisher hackers volunteering to start 
> building this? :)

I've long been wanting to build a saner publication than 
zope.app.publication. With as many modifications as we're planning, it 
might make sense to start from scratch...


Btw, I suppose we've now settled on the idea of making Grok explicitly 
*not* compatible with traditional Zope 3 browser pages defined via 
<browser:page />, right?


-- 
http://worldcookery.com -- Professional Zope documentation and training