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

[Martijn Faassen]

Hey Philipp,

Thanks for the feedback!

Before I go into your reply, I must remark that there's another issue 
surrounding this I just found out I need your guidance on: our Grok 
traversers don't work in the case of PUT, because they're registered for 
IBrowserRequest. Changing them to work for IHTTPRequest fixes this in my 
case, but can you think of any problems with that?

Philipp von Weitershausen wrote:
> Martijn Faassen wrote:
[snip]
> [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

Doing this makes it harder to have one bit of code that adds PUT to an 
object, and another bit of code that adds DELETE. I don't think this is 
a problem though - something that's going to support PUT probably should 
support DELETE right along anyway.

> 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):

Actually both PUT and POST are supposed to return something as well. 
While POST will likely do something special, PUT, as far as I understand 
is, actually is defined to return whatever GET would return. This means 
you'd like an index view to be there that PUT falls back on when it's 
done PUTting.

The alternative would be to say that people should just implement a GET 
method in this case.

>   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.

Let's summarize this idea as it stands now:

GET - use REST handler, otherwise fall back on index view
POST - use REST handler, otherwise fall back on index view
PUT - use REST handler, for results then run normal index view (as with GET)
DELETE - use REST handler. Need to research what result is expected, but 
I think that's a special HTTP status.

>> 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.).

Okay, I should say the Zope 3 publication doesn't support this out of 
the box. After a few years of bashing my head against that code I'm 
finally getting some idea of how it works, but I'm sure I'll forget it 
again soon. :)

>> 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 :).

Well, one nice thing we can say now about Grok is that there is no 
difference between the performance of Grok applications and Zope 3 
applications, where Grok is actually probably faster due to less 
security checking. Then again, you're right. Let's not worry about this.

>> 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...

I'm motivated by a Real World Project (tm) so this will have to have 
somebody else driving it. I am hoping I can start making what we've 
sketched out here work (one way or another) in the Grok core next week. 
If you think we can write a new publication machinery in a few days then 
I'd be happy to help.

> 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?

What do you mean by not compatible? I think it should remain possible to 
add a traditional <browser:page>  to a Grok model. That's our "mutual 
compatibility principle". Would there be a benefit towards breaking such 
compatibility?

Regards,

Martijn