[Grok-dev] Re: HTTP PUT and HTTP DELETE security support
Philipp von Weitershausen
philipp at weitershausen.de
Thu May 17 16:20:56 EDT 2007
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.
[snip discussion of various approaches to implementing a PUT view]
I would suggest introducing a grok.REST class:
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):
def POST(self, item_name, name='Manfred'):
self.context[item_name] = mammoth = Mammoth(name)
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'
> 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
More information about the Grok-dev