Thanks Luke for your look-again-later self code review :)
On Tue, 1 Jan 2019 at 16:51, Luke Plant wrote:
> 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
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
>
> Unless we documented the attributes/keys I'd consider it an implementation
> detail of the middleware.
Fair enough, I think I'm becoming a bit too conservative :)
On Sat, 29 Dec 2018 at 22:13, Florian Apolloner
wrote:
> Hi Adam,
>
> On Saturday, December 29, 2018 at 7:59:44 PM UTC+1, Adam
Hi Adam,
On Saturday, December 29, 2018 at 7:59:44 PM UTC+1, Adam Johnson wrote:
>
> since request.META is always there whilst attributes might not be if the
> middleware aren't set up properly?
>
request.META is always there, but the keys inside there might not be. In
that sense you have to
It looks like it dates back to the Django 1.1 refactor and extension in
https://github.com/django/django/commit/8e70cef9b67433edd70935dcc30c621d1e7fc0a0
ticket #9977, for which the referred wiki page (
https://code.djangoproject.com/wiki/CsrfProtection) is still up too with
rationales about the
Hi there,
I am considering rewriting and (hopefully) simplifying the CSRF middleware.
While looking through the code I realized that we put stuff into
request.META as well as attributes on the request object itself
(csrf_cookie_needs_reset) for instance. Is there any reason why we do not
