tgext.routes changes

[Søren Løvborg]

I would definitely not recommend copying the current _method handling. :-)

The correct thing must be an early pass where the _method override is
applied to the REQUEST_METHOD. All code beyond that point should just see
REQUEST_METHOD, and never know the difference between fake and real HTTP
verbs. Which sounds like exactly what tgext.routes 0.1.2 does.

(Aside: I did not look at the tgext.routes code, but I assume the override
support is opt-in? Enabling it automatically for all applications could
cause security issues for applications that don't have CSRF protection.)

> If I temporarily change that code so that 'DELETE' is also part of the
> accepted request methods, then test_delete fails due to 403 Forbidden
> while it expects 405 Method Not Allowed, and
> test_delete_browser_fakeout fails with 403 too (CSRF protection, I
> guess?)

Yes, and that behavior is arguably the correct one. test_delete should be
changed to expect 403, since the DELETE method is in fact allowed (but the
CSRF check is expected to fail).

Best,
Søren







On Mon, Apr 11, 2016 at 12:42 AM, Alessandro Molina <
alessandro.molina at gmail.com> wrote:

>
>
> On Sun, Apr 10, 2016 at 9:20 PM, Thomas De Schampheleire <
> patrickdepinguin at gmail.com> wrote:
>
>> Previously, using routes, we received a real POST request with
>> _method==PUT or _method==DELETE, while with Alessandro's change in
>> tgext.routes, we receive a real PUT or DELETE request, which is not
>> what the current code expects.
>>
>
> We can easily change tgext.routes to behave like routes which recovers the
> previous REQUEST_METHOD ->
> https://github.com/bbangert/routes/blob/master/routes/middleware.py#L99
>
> but I think it actually makes more sense like this as I find it more
> confusing to have routing that behaves like a DELETE method but if you ask
> request method it gives something else.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20160412/3f944402/attachment.html>