Re: Backwards-incompat with CsrfViewMiddleware

2010-02-16 Thread Ivan Sagalaev
James Bennett wrote: Perhaps that's why, in both the 1.2 alpha release notes and the draft for the final 1.2 notes, it's listed under a big heading titled "backwards-incompatible changes". As we say in Russia "Gee, I didn't notice the elephant" :-). I still think it would be useful to add an e

Re: Backwards-incompat with CsrfViewMiddleware

2010-02-16 Thread James Bennett
On Tue, Feb 16, 2010 at 4:39 AM, Ivan Sagalaev wrote: > It's not the question of responsibility. We're changing a minor version > which is supposed to be backwards compatible. If a site will break in this > case people won't go looking for some responsible person they'll just blame > Django for br

Re: Backwards-incompat with CsrfViewMiddleware

2010-02-16 Thread Ivan Sagalaev
Luke Plant wrote: This case is slightly different because it is down to an interaction of a changed default setting with working code, but there will always be cases like that, and I think it is much better for developers to remember the general principle that they are responsible for whatever

Re: Backwards-incompat with CsrfViewMiddleware

2010-02-15 Thread Luke Plant
On Monday 15 February 2010 09:20:28 Ivan Sagalaev wrote: > Hello everyone! > > A couple of days ago we've noticed a (potentially big) backwards > incompatibility that can bite users upgrading from 1.1 to 1.2. > > CSRF doc encourages users to enable CsrfViewMiddleware that will > check all POST r

Backwards-incompat with CsrfViewMiddleware

2010-02-15 Thread Ivan Sagalaev
Hello everyone! A couple of days ago we've noticed a (potentially big) backwards incompatibility that can bite users upgrading from 1.1 to 1.2. CSRF doc encourages users to enable CsrfViewMiddleware that will check all POST requests for csrf_token and then suggests to alter all HTML forms to