0

I have a templatetag which generates a form, this therefore requires the {% csrf_token %} for security, which in turn requires a RequestContext object instead of the standard Context object.

Now, the particular templatetag/form in question is included in the header of every page. Currently every page doesn't render_to_response with a RequestContext object.

Is there any way in which I can get around this issue without having to changing every view within the entire site to pass through the RequestContext?

Thanks in advance.

Nick
  • 87
  • 1
  • 6

1 Answers1

0

All though there may be some workarounds, the best practice is definitely to add the RequestContext everywhere. This has advantages for other middlewares as well.

But there is also a legacy method, that will be removed in Django 1.4 that does not require you to change all your views. I would recommend against it unless you don't have much option.

http://docs.djangoproject.com/en/dev/ref/contrib/csrf/#legacy-method

Tom Gruner
  • 9,635
  • 1
  • 20
  • 26
  • There is another way: ignore csrf for that form: http://docs.djangoproject.com/en/1.2/ref/contrib/csrf/#exceptions – alex vasi Mar 13 '11 at 21:44
  • @alex - unfortunately this is a view based exception, my problem here is with forms within templatetags. – Nick Mar 13 '11 at 22:02
  • @orangutancloud - Is there anything I would need to be concerned about with using RequestContext everywhere - security, performance or otherwise? Thanks. – Nick Mar 13 '11 at 22:04
  • @Nick, but there must be a view that handles the form's POST data. So that decorator is for that view. – alex vasi Mar 13 '11 at 23:01
  • @alex, RequestContext is secure and should be very fast as long as you take care that any custom context processors you write and add are also fast and secure. The django context processors are already fast and secure. Unless you are going for some extreme optimization, this will not slow things down at all. – Tom Gruner Mar 13 '11 at 23:12
  • @alex, the problem I was having was that the form is generated by a templatetag within the site header. Which therefore could be within any view. I therefore had no option but to include RequestContext within all views. – Nick Mar 16 '11 at 20:07