CsrfResponseMiddleware breaks the Etag in CommonMiddleware
|Reported by:||defaultwombat||Owned by:||nobody|
|Severity:||Keywords:||csrf etag middleware never_cache|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
If the CsrfResponseMiddleware.process_response adds the csrf_token field to the content the etag of the response doesn't get updated.
The CommonMiddleware.process_response however only generates a new etag if it doesn't already exist.
So the comparison between HTTP_IF_NONE_MATCH and Etag is based on a wrong etag and might lead to a wrong HttpResponseNotModified.
My problem was that I sometimes got a 403 from the csrf-middleware when i added or changed things in the admin site.
Although I haven't resolved the whole puzzle yet, the main pieces are:
- When you use a admin form the etag is generated by the never_cache decorator.
- The csrf middleware adds the csrf_token field to the form
- If your browser doesn't have the page cached everything is fine
- When you logout and login again and you get a new session_id
- If you now use the same admin form again the common middleware doesn't notice any changes beween the HTTP_IF_NONE_MATCH and the etag.
- So it sends a HttpResponseNotModified which let the browser use the cached version of the page.
- As the csrf_token in the cached page is based on a different session_id you end up with a 403 when you try to submit the form.