Haven't enabled CSRF protection and yet server throws CSRF based 403

[Filip Gruszczyński]

I have just upgraded to 1.2 and when I run ./manage runserver and
tried to open main page of our project first I was asked to login and
when I hit enter I got:

Forbidden (403)
CSRF verification failed. Request aborted.

I haven't turned CSRF protection when I was using 1.1.1, so my project
should be ready to go, but it isn't. What I might be doing still
wrong?

[Kenneth Gonsalves]

Post by Filip Gruszczyński
I have just upgraded to 1.2 and when I run ./manage runserver and
tried to open main page of our project first I was asked to login and
Forbidden (403)
CSRF verification failed. Request aborted.
I haven't turned CSRF protection when I was using 1.1.1, so my project
should be ready to go, but it isn't. What I might be doing still
wrong?

it is on by default isn't it?
--
Regards
Kenneth Gonsalves
Senior Associate
NRC-FOSS at AU-KBC

[Filip Gruszczyński]

Docs say:

If you do not have any of the middleware in your MIDDLEWARE_CLASSES,
you will have a working installation but without any CSRF protection
for your views (just as you had before). It is strongly recommended to
install CsrfViewMiddleware and CsrfResponseMiddleware, as described
above.

So I thought I don't have to do anything. Can I disable it somehow?

Post by Kenneth Gonsalves

Post by Filip Gruszczyński
I have just upgraded to 1.2 and when I run ./manage runserver and
tried to open main page of our project first I was asked to login and
Forbidden (403)
CSRF verification failed. Request aborted.
I haven't turned CSRF protection when I was using 1.1.1, so my project
should be ready to go, but it isn't. What I might be doing still
wrong?

it is on by default isn't it?
--
Regards
Kenneth Gonsalves
Senior Associate
NRC-FOSS at AU-KBC
--
You received this message because you are subscribed to the Google Groups "Django users" group.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

[Karen Tracey]

Post by Filip Gruszczyński
If you do not have any of the middleware in your MIDDLEWARE_CLASSES,
you will have a working installation but without any CSRF protection
for your views (just as you had before). It is strongly recommended to
install CsrfViewMiddleware and CsrfResponseMiddleware, as described
above.
So I thought I don't have to do anything. Can I disable it somehow?

I suspect you are using the contrib.auth login view. All contrib app views
use the csrf_protect decorator ("All contrib apps use a csrf_protect
decorator to protect the view. This requires the use of the csrf_token
template tag in the template. If you have used custom templates for contrib
views, you MUST READ THE UPGRADE INSTRUCTIONS to fix those templates.") You
need to update the login template you are using to include the {% csrf_token
%} tag.

Karen

[Filip Gruszczyński]

Post by Karen Tracey
I suspect you are using the contrib.auth login view. All contrib app views
use the csrf_protect decorator ("All contrib apps use a csrf_protect
decorator to protect the view. This requires the use of the csrf_token
template tag in the template. If you have used custom templates for contrib
views, you MUST READ THE UPGRADE INSTRUCTIONS to fix those templates.") You
need to update the login template you are using to include the {% csrf_token
%} tag.

Thanks a lot, Karen. You are always right ;-) and this time it worked too :-)

[Kenneth Gonsalves]

Post by Filip Gruszczyński
If you do not have any of the middleware in your MIDDLEWARE_CLASSES,
you will have a working installation but without any CSRF protection
for your views (just as you had before). It is strongly recommended to
install CsrfViewMiddleware and CsrfResponseMiddleware, as described
above.
So I thought I don't have to do anything. Can I disable it somehow?

rather than disable it, why do you not use it? it's going to be there for a
long time, and although it is a bit tedious to enable it, it is worth doing
once and for all - remember that this is practically the only security hole
found in django after nearly 5 years of release.
--
Regards
Kenneth Gonsalves
Senior Associate
NRC-FOSS at AU-KBC

[Filip Gruszczyński]

Post by Kenneth Gonsalves
rather than disable it, why do you not use it? it's going to be there for a
long time, and although it is a bit tedious to enable it, it is worth doing
once and for all - remember that this is practically the only security hole
found in django after nearly 5 years of release.

I guess we will slowly move in this direction, but for now I just
would like to upgrade our project to 1.2, because it has some feature
we would like use.