CSRF verification failures (admin)
PieterB
failed" errors... most of the times when using the admin interface
It doesn't happen with the local dev version (dev http server) but
happens with the deployment version (custom port, cherokee web server)
I can only use the admin interface (very) temporarily with a Clear
Recent History command
This is very annoying :-S
I've included
'django.middleware.csrf.CsrfViewMiddleware',
'django.middleware.csrf.CsrfResponseMiddleware'
What am I doing wrong? Do I need also some sort of token for Django's
admin interface?
-- PieterB
Alex Robbins
template from django before 1.2, then upgraded, your admin template
might be missing the csrf_token template tag.
Alex
PieterB
I've only a modified (created) admin.py for each app in the project.
Maybe this is also important: we use a proxy, maybe it's something
with the cache?
What can cause csrf verification to go crazy?
James Saxon
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
--
J A M E S B E N N E T T S A X O N ja...@saxon.com
Biz: 310.823.0545 - Cell: 310.722.2785
PieterB
I tried some middleware code I found on the web, but I get
ImproperlyConfigured: CsrfMiddleware isn't a middleware module
(but this is probably me doing something wrong?)
http://johnmc.co/llum/disable-csrf-protection-for-django-1-2/
http://stackoverflow.com/questions/1650941/django-csrf-framework-cannot-be-disabled-and-is-breaking-my-site
The last thing I want to do is to remove it from django itself...
I'm pretty sure it's a useful solution for web-facing projects, but
it's giving me al lot of headaches for this one :-(
> > .
Russell Keith-Magee
> Can it be disabled globally?
If you have a Django 1.1 project that you have upgraded to 1.2, then
CSRF protection will *not* be enabled by default. In order to enable
it, you need to follow the migration instructions in the 1.2 release
notes.
The exception to this rule is the admin site; the admin site has CSRF
protection turned on, and no, it can't be turned off. We have
intentionally added CSRF protection as a non-optional part of the
admin as a safety mechanism. Django's admin app is a common and highly
visible component of Django projects, and as a result, it is a likely
target for any malicious activity. Forcing CSRF protection on the
admin is our way of ensuring that Django's admin site is not the
vector used to attack a Django site.
Yours,
Russ Magee %-)
> To unsubscribe from this group, send email to django-users...@googlegroups.com.
Russell Keith-Magee
> No I did not.
> I've only a modified (created) admin.py for each app in the project.
>
> Maybe this is also important: we use a proxy, maybe it's something
> with the cache?
> What can cause csrf verification to go crazy?
Depends on the operation of your proxy cache. If it's not handling
cookies correctly, then this could be the source of your problem.
At it's core, the CSRF process is simple. You visit a view. Your
browser gets a CSRF cookie set. You submit a form. That form
submission must provide the CSRF token as a form element. If the csrf
token on the submitted form does not exist, or doesn't match the
cookie, the form submission is rejected as a CSRF failure.
There are really only three things that can go wrong in the CSRF process:
* The cookie wasn't set when the form was originally requested
* The cookie isn't submitted along with the POST request
* The form data doesn't contain the CSRF token.
As I've said in other threads recently, we (the Django core team) take
backwards compatibility *very* seriously. We are not aware of any
backwards compatibility problems in Django 1.2, caused by the CSRF
framework or otherwise. We believe the release notes document all the
possible problems you may encounter as part of the upgrading process.
If you can provide any evidence to the contrary, we would consider it
a major flaw, and it would almost certainly simulate a point release
to correct the problem.
Yours,
Russ Magee %-)
Russell Keith-Magee
> I've run into a similar situation where I'm getting CSRF errors
> inconsistently. I made sure I had the token and that I was using
> RequestContext. I haven't found out exactly what's wrong yet...
> I have not run into the situation in the admin but I have not tried it much
> but I haven't changed any admin templates.
> It does seem to be something happening on the testing server but not on my
> mac in dev....
> Hmmm..
Suffice to say, this isn't a problem that we have seen during release
testing. Any assistance you can provide in tracking this problem would
be gratefully received.
Yours,
Russ Magee %-)
Aspontus
I have run into a consistent CSRF error in admin.
It occurs when user tries to change his/her password.
Every single time it returns CSRF error.
My admin templates are not modified.
Best regards
> > .
Russell Keith-Magee
> Hi.
> I have run into a consistent CSRF error in admin.
> It occurs when user tries to change his/her password.
> Every single time it returns CSRF error.
> My admin templates are not modified.
You're going to need to provide more detail than that.
Django has an extensive test suite, and it's currently passing without errors.
We have a very large userbase that has deployed Django 1.2 and not
reported any problems.
I have personally run many dozens of manual tests, including changing
a user's password, and have had no problems.
Allow me to assure you that we have tested this. If you are
experiencing problems, then there is something unusual going on, and
we need as much detail as possible. "It doesn't work" doesn't help us.
Exact browsers configurations, server configurations, minimal sample
projects -- these are the things that will help us identify and fix
this problem. We can't help you until we can duplication your problem.
Yours,
Russ Magee %-)
Jirka Vejrazka
> It occurs when user tries to change his/her password.
> Every single time it returns CSRF error.
> My admin templates are not modified.
Hi,
I'm not sure what your specific problem might be, but I experienced
CSRF problem in admin in 2 situations:
- cookies disabled in browser for the site (and long forgotten by me :)
- running admin on SSL-enabled site and having faulty browser addin
that was stripping referer values even for SSL sites.
HTH
Jirka
Aspontus
Server is running:
- Debian GNU/Linux 5.0 with 2.6.32.2 kernel
- Python 2.5.2
- Django 1.2.1
- MySQL 5.0.51 (with MySQLdb 1.2.2) - default engine InnoDB
- Apache2 with mod_python 3.3.1
Browsers are in default polish configuration and I've tested it with
Firefox 3.5.11, Safari 5.0.1, Opera 10.60, Internet Explorer 8.0.6001,
Lunascape 6.2.0, SeaMonkey 2.0.6, Google Chrome 5.0.375 (all of them
under Windows XP 32 bit PL) and Firefox 3.6 under Ubuntu 9.10 64 bit
HTML I can see when I go for "/admin/auth/user/1/password/" :
<form action="" method="post" id="user_form"><div
style='display:none'><input type='hidden' name='csrfmiddlewaretoken'
value='<value cut out>' /></div>
<p>Podaj nowe hasło dla użytkownika <strong>asp</strong>.</p>
<fieldset class="module aligned">
<div class="form-row">
<label for="id_password1" class="required">Hasło:</label> <input
type="password" name="password1" id="id_password1" />
</div>
<div class="form-row">
<label for="id_password2" class="required">Hasło (powtórz):</label>
<input type="password" name="password2" id="id_password2" />
<p class="help">Podaj powyższe hasło w celu weryfikacji.</p>
</div>
</fieldset>
<div class="submit-row">
<input type="submit" value="Zmiana hasła" class="default" />
</div>
<script type="text/
javascript">document.getElementById("id_password1").foc us();</
script>
</div>
</form>
HTML I can see when I go for "/admin/password_change/"
<form action="" method="post">
<p class="aligned wide"><label for="id_old_password">Old password:</
label><input type="password" name="old_password"
id="id_old_password" /></p>
<p class="aligned wide"><label for="id_new_password1">Nowe hasło:</
label><input type="password" name="new_password1"
id="id_new_password1" /></p>
<p class="aligned wide"><label for="id_new_password2">Potwierdź
hasło:</label><input type="password" name="new_password2"
id="id_new_password2" /></p>
<p><input type="submit" value="Zmień hasło" /></p>
</form>
It seems, that the CSRF token is somehow missing in that second case.
I hope it helps.
Best regards
On 18 Sie, 13:56, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
Russell Keith-Magee
> Sorry, I haven't thought it through.
> Server is running:
> - Debian GNU/Linux 5.0 with 2.6.32.2 kernel
> - Python 2.5.2
> - Django 1.2.1
> - MySQL 5.0.51 (with MySQLdb 1.2.2) - default engine InnoDB
> - Apache2 with mod_python 3.3.1
> Browsers are in default polish configuration and I've tested it with
>
> Firefox 3.5.11, Safari 5.0.1, Opera 10.60, Internet Explorer 8.0.6001,
> Lunascape 6.2.0, SeaMonkey 2.0.6, Google Chrome 5.0.375 (all of them
> under Windows XP 32 bit PL) and Firefox 3.6 under Ubuntu 9.10 64 bit
>
Agreed - which means it's not a complex browser issue, it's a
configuration issue with your Django project. At first guess, either:
* Your TEMPLATE_DIRS setting is pointing to a directory with pre-1.2 templates
* Your Django install is running pre-1.2 code, or using stale pyc
files (which might mean you're loading templates from the wrong app
directory)
* You have overridden the auth/user/change_password.html template
* You have installed an app that overrides the
auth/user/change_password.html template
To demonstrate the point -- go to the Django install that you think
you are using, and change the
django/contrib/admin/templates/admin/auth/user/change_password.html
template, putting in some dummy content (e.g., "I WAS HERE") at the
top of the form where the CSRF token should be. Then re-render the
form. If you don't get your new content, then you've found the problem
-- you're not rendering the template you think you are.
Yours,
Russ Magee %-)
PieterB
wrote:
> * Your TEMPLATE_DIRS setting is pointing to a directory with pre-1.2 templates
> * Your Django install is running pre-1.2 code, or using stale pyc
> files (which might mean you're loading templates from the wrong app
> directory)
> * You have overridden the auth/user/change_password.html template
> * You have installed an app that overrides the
> auth/user/change_password.html template
I just deployed django 1.2 on python 2.4 on RHEL
no changes in the admin code...
Maybe It's due to some plugin in Firefox ? I will test again with
another plugin showing my session/POST variables :-)
Matthias Runge
> I'm doing none of the above.
> I just deployed django 1.2 on python 2.4 on RHEL
> no changes in the admin code...
> Maybe It's due to some plugin in Firefox ? I will test again with
> another plugin showing my session/POST variables :-)
>
I've seen some strange errors with Django and python 2.4 on RHEL 5.x.
Solution for me was to deploy the same code on fedora using python 2.5
or higher.
Matthias
Aspontus
The template django/contrib/admin/templates/admin/auth/user/
change_password.html You point me to is rendered when I use the
password change form from user change form.
The one that seems to be missing CSRF token is rendered when I try to
change password from the link in the upper right corner of admin
screen.
I think that it is some other template, as the form's fields ids are
different - namely id_old_password, id_new_password1 and
id_new_password_2, while in the aforementioned template the form's
fields ids are id_password1 and id_password2.
I think that the template rendered in this case is django/contrib/
admin/templates/registration/password_change_form.html
Is this something I can change and if so then how? The link I am
referring to is part of django/contrib/admin/templates/admin/base.html
and looks like this:
{% url admin:password_change as password_change_url %}
{% if password_change_url %}
<a href="{{ password_change_url }}">
{% else %}
<a href="{{ root_path }}password_change/">
{% endif %}
{% trans 'Change password' %}</a>
Best regards
On 19 Sie, 02:09, Russell Keith-Magee <russ...@keith-magee.com> wrote:
> 2010/8/18 Aspontus <aspon...@gmail.com>:
Karen Tracey
It seems I haven't expressed myself clearly enough.
The template django/contrib/admin/templates/admin/auth/user/
change_password.html You point me to is rendered when I use the
password change form from user change form.
The one that seems to be missing CSRF token is rendered when I try to
change password from the link in the upper right corner of admin
screen.
I think that it is some other template, as the form's fields ids are
different - namely id_old_password, id_new_password1 and
id_new_password_2, while in the aforementioned template the form's
fields ids are id_password1 and id_password2.
I think that the template rendered in this case is django/contrib/
admin/templates/registration/password_change_form.html
Is this something I can change and if so then how?
Note that template in the 1.2 release:
http://code.djangoproject.com/browser/django/tags/releases/1.2/django/contrib/admin/templates/registration/password_change_form.html
does have the {% csrf_token %} tag in the form (on line 11).
So check the copy of that template in your install -- if it does not have {% csrf_token %} on line 11 then somehow your installed files differ from the release files. If it does, then for your project some other template is being used to override that one in the install, and you need to find that override and fix it to include the csrf token.
Karen
--
http://tracey.org/kmt/
Aspontus
I've found the old template.
I've asked server administrator to remove it and now it works.
Best regards
On 19 Sie, 13:06, Karen Tracey <kmtra...@gmail.com> wrote:
> > It seems I haven't expressed myself clearly enough.
> > The template django/contrib/admin/templates/admin/auth/user/
> > change_password.html You point me to is rendered when I use the
> > password change form from user change form.
> > The one that seems to be missing CSRF token is rendered when I try to
> > change password from the link in the upper right corner of admin
> > screen.
> > I think that it is some other template, as the form's fields ids are
> > different - namely id_old_password, id_new_password1 and
> > id_new_password_2, while in the aforementioned template the form's
> > fields ids are id_password1 and id_password2.
> > I think that the template rendered in this case is django/contrib/
> > admin/templates/registration/password_change_form.html
> > Is this something I can change and if so then how?
>
> Note that template in the 1.2 release:
>