1👍
I’m not an expert, but you may try using GET instead of POST. See http://groups.google.com/group/django-non-relational/browse_thread/thread/e6baed5291aed957/d6c42150c8e246e1?lnk=gst&q=queue#d6c42150c8e246e1 (the last entry)
5👍
If you have the CsrfViewMiddleware
enabled, Django will require a csrf_token
in all POSTs to your views.
Django provides a decorator, @csrf_exempt
, that you should place on your task queue views. This turns off the middleware just for those views.
Alternatively, you can avoid using CsrfViewMiddleware
altogether and instead use the @csrf_protect
decorator where you need it. I don’t recommend doing this — it’s probably safer to protect everywhere and carve out a small number of exemptions for your task queue views.
(One last note: both answers above — that something is wrong with your view, or that you should just use GET for the task queue — strike me wrong. There’s nothing wrong with your view, and POST is the right verb to use for task queue tasks.)
- [Django]-How to include null results in Django ORM queries
- [Django]-Django – CreateView – Send a custom Error Message if model form is not valid
3👍
Looking at the source of csrf.py, it looks like this would only occur if your view function is returning None (or not explicitly returning, in which case Python would return None implicitly). Looking at your code, I don’t see how that could occur, though – are you sure this is your exact deployed code?
Also, you probably don’t want to use get_object_or_404
inside a task queue task – if it can’t find the object, it’ll throw a 404, which will cause the task to error and retry indefinitely.
You also shouldn’t need CSRF protection (per your TODO); instead, make sure the task queue URL is marked admin-only, and it will only ever be called by the task queue service.