On Oct 21, 2011, at 8:04 AM, Kääriäinen Anssi wrote: > I do not know nearly enough about caching to participate fully in this > discussion. But it strikes me that the attempt to have CSRF protected > anonymous page cached is not that smart. If you have an anonymous submittable > form, why bother with CSRF protection? I mean, what is it protecting against? > Making complex arrangements in the caching layer for this use case seems like > wasted effort. Or am I missing something obvious?
First issue is that CSRF can matter for anonymous users. From here http://www.squarefree.com/securitytips/web-developers.html#CSRF: Attacks can also be based on the victim's IP address rather than cookies: • Post an anonymous comment that is shown as coming from the victim's IP address. ... • Perform a distributed password-guessing attack without a botnet. (This assumes they have a way to tell whether the login succeeded, perhaps by submitting a second form that isn't protected against CSRF.) So two very common uses cases for anonymous forms are log in forms and anonymous comment forms, both of which are potentially vulnerable. I guess I feel like it's quite common to have forms on a page these days even for anonymous users. Second is -- and I don't know about this -- but I don't know how well CSRF handles authentication conditionally. Like if I have a page and let's say that page has forms in it for logged in users but nothing for anonymous user, can I conditionally exempt the formless page from CSRF? I have no idea, but buy default I presume it's on and I presume the cache is varying on it. So, yes, you could probably optimize a lot of this to sort of skip around the CSRF issue and it's not a deal breaker. But my main argument has been the ubiquity of CSRF + user authentication in Django projects to me means a solution to both of these is a requirement for page caching to become easy and applicable in most scenarios. > > The following is from the stupid ideas department: Maybe there could be a > "reverse cache" template tag, such that you would mark the places where you > want changing content as non-cacheable. You would need two views for this, > one which would construct the "base content" and then another which would > construct the dynamic parts. Something like: > Your idea sounds a lot like the "server side include" or "two phased template rendering" approach that I know some people are doing. Here's an excellent example of this approach being used in EveryBlock (from two years ago): http://www.holovaty.com/writing/django-two-phased-rendering/ And looks like some core devs have been involved at some point in this implementation of that concept: https://github.com/codysoyland/django-phased That looks almost exactly like your idea: "django-phased contains a templatetag, phased, which defines blocks that are to be parsed during the second phase. A middleware class, PhasedRenderMiddleware, processes the response to render the parts that were skipped during the first rendering." I guess that was sort of what I was hinting at in my previous discussion about how to handle CSRF. In the link he is taking it to the next level (where even logged in users get the page and that stuff is done after. Anyhow it's obviously a sensible conceptual approach. It would be a stretch to fit that into the existing page caching approach of Django obviously. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
