On Sat, Mar 21, 2009 at 2:25 PM, James Bennett wrote:
>
> On Sat, Mar 21, 2009 at 11:24 AM, Alex Gaynor
> wrote:
> > b) Having the admin be CSRF safe by default doesn't seam like a feature,
> it
> > feels like a bug, even if it's implementation gives everything a new
> > feature. That's just my
On Sat, Mar 21, 2009 at 11:24 AM, Alex Gaynor wrote:
> b) Having the admin be CSRF safe by default doesn't seam like a feature, it
> feels like a bug, even if it's implementation gives everything a new
> feature. That's just my thoughts though.
Personally I'd much rather have it actually *be* s
> Too late now since it's already committed, but I've got some serious
> reservations about this one. More development effort should have gone
> into improving and refactoring the middleware before it got
> automatically enabled.
I agree with James here. With apologies to Luke, the CSRF middlewa
On Sat, Mar 21, 2009 at 12:20 PM, Luke Plant wrote:
>
> Hi Adrian,
>
> On Saturday 21 March 2009 01:47:08 Adrian Holovaty wrote:
>
> > I've been traveling since Tuesday, and, shall we say, I'm not that
> > excited about this being in the default middleware. In fact, I'm +1
> > for reverting this
Hi Adrian,
On Saturday 21 March 2009 01:47:08 Adrian Holovaty wrote:
> I've been traveling since Tuesday, and, shall we say, I'm not that
> excited about this being in the default middleware. In fact, I'm +1
> for reverting this change and might even want to exercise the
> benevolent dictator ve
On Thu, Mar 19, 2009 at 9:03 PM, James Bennett wrote:
> Too late now since it's already committed, but I've got some serious
> reservations about this one. More development effort should have gone
> into improving and refactoring the middleware before it got
> automatically enabled.
Hmm, yeah...
On Wed, Mar 18, 2009 at 10:59 AM, Jacob Kaplan-Moss
wrote:
> I'm a somewhat reluctant +0 on this -- the content re-writing that the
> CSRF middleware does has always rubbed me the wrong way. For one,
> it'll make implementing streaming responses quite a bit more
> difficult. But more importantly
On Thursday 19 March 2009 19:18:19 Bob Thomas wrote:
> On Mar 19, 2:49 pm, Luke Plant wrote:
> > The hard work isn't the template tag, it's:
> >
> > - tests (the existing ones are in django/contrib/csrf/tests.py)
> > - documentation
> > - converting the admin (I really think this needs to be d
>
> also, please note that even if GET requests are mostly readonly,
> if they return JSON, they can be still read by a CSRF attack,
> so those have to be secured ( usually be verifying
> the special header set by ajax requests ).
>
> gabor
That's more of a "JSON hijacking" attack than CSRF. It
On Thu, Mar 19, 2009 at 9:53 AM, Thomas Guettler wrote:
>
> The CSRF middleware inserts a hidden input element in every form.
>
> Since GET Requests are mostly readonly, the bad guy needs a POST
> request to do some evil.
>
> If the bad guy can make a POST request
> with the user's browser, the b
On Mar 19, 3:42 pm, Jacob Kaplan-Moss
wrote:
> On Thu, Mar 19, 2009 at 2:18 PM, Bob Thomas wrote:
> > So, if the template tag wasn't hard enough to write, it's not helpful?
>
> Um. That's not what I read from what Luke's saying.
>
That's what I read, though.
> Again, that's not at all what I
On Thu, Mar 19, 2009 at 2:18 PM, Bob Thomas wrote:
> So, if the template tag wasn't hard enough to write, it's not helpful?
Um. That's not what I read from what Luke's saying.
> I'm not sure how I missed the tests, though. I think I was just
> looking at the regression tests for the built-in ta
On Mar 19, 2:49 pm, Luke Plant wrote:
> The hard work isn't the template tag, it's:
>
> - tests (the existing ones are in django/contrib/csrf/tests.py)
> - documentation
> - converting the admin (I really think this needs to be done
> before we can check this in, because we want to depreca
On Thursday 19 March 2009 15:55:35 Bob Thomas wrote:
> On Mar 18, 1:25 pm, Luke Plant wrote:
> > Yep, agreed. I plan to replace the content re-writing stuff with
> > a template tag which hopefully won't be too nasty. It's just I
> > haven't had time yet, and I'd rather fix the security hole now,
On Mar 18, 1:25 pm, Luke Plant wrote:
>
> Yep, agreed. I plan to replace the content re-writing stuff with a
> template tag which hopefully won't be too nasty. It's just I haven't
> had time yet, and I'd rather fix the security hole now, and improve
> the implementation later. The exception me
On Thursday 19 March 2009 08:53:06 Thomas Guettler wrote:
> The CSRF middleware inserts a hidden input element in every form.
>
> Since GET Requests are mostly readonly, the bad guy needs a POST
> request to do some evil.
>
> If the bad guy can make a POST request
> with the user's browser, the b
The CSRF middleware inserts a hidden input element in every form.
Since GET Requests are mostly readonly, the bad guy needs a POST
request to do some evil.
If the bad guy can make a POST request
with the user's browser, the bad guy might make a GET request with javascript
first , read the hidden
On Wednesday 18 March 2009 15:59:10 Jacob Kaplan-Moss wrote:
> On Wed, Mar 18, 2009 at 8:40 AM, Luke Plant
wrote:
> > I propose adding the two [CSRF] middleware (view and response) to
> > the MIDDLEWARE settings [...]
>
> I'm a somewhat reluctant +0 on this -- the content re-writing that
> the C
On Wed, Mar 18, 2009 at 8:40 AM, Luke Plant wrote:
> I propose adding the two [CSRF] middleware (view and response) to the
> MIDDLEWARE
> settings [...]
I'm a somewhat reluctant +0 on this -- the content re-writing that the
CSRF middleware does has always rubbed me the wrong way. For one,
it'll
I have not been able to implement all of the CSRF proposals we made a
while back in time for the beta (in particular, replacing the current
CsrfResponseMiddleware with a template tag).
However, significant improvements have been made, and it is much more
useful by default. I propose adding th
20 matches
Mail list logo
