Re: HTTP POST sent from app to Django Server returns 403 Forbidden

On 28/07/10 03:45, Kieran Farr wrote:
> Finally figured out what's going on.
>
> My hypothesis:
> An HTTP request with POST method sent to a Django view wrapped with
> @csrf_exempt will still raise a 403 CSRF error if the wrapped view
> raises an Http404 exception.
>

Ah, but was your handler404 view csrf_exempt (the default django one
django.views.defaults.page_not_found isn't...) ;-)

http://code.djangoproject.com/browser/django/trunk/django/views/defaults.py#L4

(really, you'd probably better off _returning_ a
django.http.HttpResponseNotFound response than raising a Http404
exception from your exempted view in this case I guess).

IMO there's no reason to leak info even to the extent of "this object
doesn't exist" to scurrilous CSRFers by default.

> Is there a better way to provide debugging information for 403 errors
> raised from the built-in CSRF methods?
>

Note also that django 1.2.1 allows specification of
settings.CSRF_FAILURE_VIEW.

http://docs.djangoproject.com/en/dev/ref/settings/?from=olddocs#csrf-failure-view

You could even make that view immediately throw an exception to be
caught by something else ...I think.

There are quirks, or at least things to be aware of, with the order
things happen in django.core.handlers.base.BaseHandler.get_response()
[1]. Note an exception middleware /doesn't catch/ all exceptions,
some "escape" if they happen early, so e.g. it's best to still specify a
custom handler404/handler500 when using an exception middleware, because
they might still get called.

Even then the only way I've found to completely customize the behaviour
when settings.DEBUG is true (because I wanted ajax technical_response
debug pages to be specially formatted compared to standard whole-page
technical_response) is to subclass the Handler (WSGIHandler) to meddle
with get_response.

I hesitate to call the situation a "bug", because it's all stuff you
probably shouldn't be messing with much, making it too easy
to render your server insecure is probably a django non-goal...

[1]
http://code.djangoproject.com/browser/django/trunk/django/core/handlers/base.py#L66

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.