--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/43f6d8da-c66c-4100-a6d6-e85d4cef3684%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
since request.META is always there whilst attributes might not be if the middleware aren't set up properly?
It seems like it could just be oversight. I would think that moving would require a standard deprecation period.
Unless we documented the attributes/keys I'd consider it an implementation detail of the middleware.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/fa76d5eb-68c6-4f9d-859d-3eb48011ae23%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hi Florian,
My own instincts would be steer away from writing to request.META for most things, because request.META also contains things from the environment and indeed from the user request. You really don't want an attacker to be able to set an HTTP header and bypass security controls or directly influence anything which is supposed to be from application/framework code.
Of course, all arbitrary HTTP request headers are mapped to `request.META['HTTP_ …`, while some specific ones have special mappings, but I'd rather not have to think about that kind of thing when doing security audits. With attributes it is always very clear where they have come from.
In addition, looking at the docs for request.META
it is confusing to users if there are things in there that have
not originated directly from the request.
As the original author of the CSRF stuff, I have no idea now why
I used request.META for some things, if indeed it was me who did
it that way — attributes seems much better for those usages.
Luke
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/43f6d8da-c66c-4100-a6d6-e85d4cef3684%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9fb674dc-df9a-0c86-8e93-3465b8a596bb%40cantab.net.
For more options, visit https://groups.google.com/d/optout.