Why not remove csrfmiddlewaretoken in CsrfViewMiddleware from request.POST?
I have various views which break on the additional csrfmiddlewaretoken in request.POST when using the recommendet CSRF protection with CsrfViewMiddleware and {% csrf_token %}. Why don't we just remove the csrfmiddlewaretoken in CsrfViewMiddleware before the request hits the views? patch on middleware/csrf.py 1.2.1 final: 11a12 > from django import http 162a164,167 > tmp_post = request.POST.copy() > del tmp_post['csrfmiddlewaretoken'] > request.POST = http.QueryDict(tmp_post.urlencode()) My code seems to work and the CSRF protection is now completely transparent to the views. Only the templates and the MIDDLEWARE_CLASSES need to know about it. Regards, Dirk -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Why not remove csrfmiddlewaretoken from request.POST?
I have various views which break on the additional csrfmiddlewaretoken in request.POST when using the recommendet CSRF protection with CsrfViewMiddleware and {% csrf_token %}. Why don't we just remove the csrfmiddlewaretoken before the request hits the views? patch on middleware/csrf.py 1.2.1 final: 11a12 > from django import http 162a164,167 > > tmp_post = request.POST.copy() > del tmp_post['csrfmiddlewaretoken'] > request.POST = http.QueryDict(tmp_post.urlencode()) My code seems to work and the CSRF protection is now completely transparent to the views. Only the templates and the MIDDLEWARE_CLASSES needs to know about it. Regards, Dirk -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Missing REFERENCES... in SQL of models.ForeignKey('LaterDefinedModel')
On Jan 31, 2:31 am, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > On Sat, 2009-01-31 at 12:20 +1100, Malcolm Tredinnick wrote: > > On Fri, 2009-01-30 at 09:49 -0800, mucisland wrote: > > > Hi all. > > > > If I specify the ForeignKey target model as a string because it is not > > > yet defined, the (SQLite3) SQL table entry misses the REFERENCES > > > specifier. Example: > > > SQLite doesn't support "references" constraints. So we don't bother > > writing them out (it doesn't support relations). There's no bug here. > > When I said "doesn't support relations", I meant "doesn't *enforce* > relations* at the database level. You can still use foreign keys and > many-to-many fields and the like in Django. But the data integrity at > the database level isn't enforced by SQLite. Thanks for your answer, Malcolm! So I assume the PostgreSQL backend would write the references constrained into the SQL? And for the SQLite3 backend, it's strange that it sometimes writes the references constraint and sometimes not. I stress this point because I'd like to have a stable SQL database scheme before I enter my data. Loading serialized data into a changed database scheme is a PITA, or I just didn't find the right way to do it yet... Best Regards, Dirk --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Missing REFERENCES... in SQL of models.ForeignKey('LaterDefinedModel')
Hi all. If I specify the ForeignKey target model as a string because it is not yet defined, the (SQLite3) SQL table entry misses the REFERENCES specifier. Example: class Department(models.Model): head = models.ForeignKey('Person', related_name='heads') class Person(models.Model): department = models.ForeignKey(Department) results in the following SQL: CREATE TABLE "common_department" ( "id" integer NOT NULL PRIMARY KEY, "head_id" integer NOT NULL); CREATE TABLE "common_person" ( "id" integer NOT NULL PRIMARY KEY, "department_id" integer NOT NULL REFERENCES "common_department" ("id")); Is the missing REFERENCES in the department table a Django bug? Thanks for your time, Dirk --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---