#28699: Document middleware ordering requirements following CSRF change in 
     Reporter:  stephanm       |                    Owner:  Rodrigo
         Type:  Bug            |                   Status:  assigned
    Component:  Documentation  |                  Version:  1.11
     Severity:  Normal         |               Resolution:
     Keywords:                 |             Triage Stage:  Accepted
    Has patch:  1              |      Needs documentation:  0
  Needs tests:  0              |  Patch needs improvement:  0
Easy pickings:  0              |                    UI/UX:  0

Comment (by Carlton Gibson):

 The PR here looks fine, re the discussion, but I'm missing a crucial part
 in my understanding here: I can't see how you're meant to make a
 successful CSRF check in the **same request** as a `REMOTE_USER` login...

 As I read it, if `RemoteUserMiddleware` is first then:

 * `RemoteUserMiddleware.process_request()` calls `auth.login()` which
 calls `rotate_token()`:

 def rotate_token(request):
     Change the CSRF token in use for a request - should be done on login
     for security purposes.
         "CSRF_COOKIE_USED": True,
         "CSRF_COOKIE": _get_new_csrf_token(),
     request.csrf_cookie_needs_reset = True

 * But then `CsrfViewMiddleware.process_request()` calls `_get_token()`
 which fetches the **old** `CSRF_COOKIE`, from either the session or the
 cookie, and
 resets it on `request.META`].

 Unless I missed something, this is **negating the `rotate_token()` call**.
 Is that correct, or have I misread it? Given the docstring in
 `rotate_token()` isn't this a no-no?

 On the other hand, if `CsrfViewMiddleware` is first then the
 `rotate_token()` call will replace whatever `CSRF_COOKIE` was previously
 set, and so the actual CSRF check in `process_view()` will necessarily
 fail. (As we must be seeing here.)

Ticket URL: <https://code.djangoproject.com/ticket/28699#comment:16>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to