#28699: Document that REMOTE_USER must be logged in before making CSRF protected
requests.
-------------------------------+------------------------------------
Reporter: stephanm | Owner: Rodrigo
Type: Bug | Status: assigned
Component: Documentation | Version: 1.11
Severity: Normal | Resolution:
Keywords: remote user | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
Comment (by Rodrigo):
Replying to [comment:22 Carlton Gibson]:
> > For this ticket I think documenting that remote user auth will require
two requests — one to login, on to submit further data passing CSRF — is
the best we can do.
>
> Actually, I'm not exactly sure what to say here. Thinking about it,
exactly the same considerations apply to all login. You'd have to take
special measures to login a user and submit additional form data, whilst
also checking CSRF, in a single request, even if you were using session
based authentication with the model backend. (You'd write a view to do it,
manually calling `login()` yourself...)
>
> I'm kind of inclined towards `wontfix` for that reason...
I am not sure if I am understanding, there will be always one extra
request for getting the CSRF token before POSTing anything. The
rotate_token() is called only by login(), the RemoteUserMiddleware calls
it only when user is not auth'ed (otherwise it just return) - which as you
said before, it will be negated later by CSRF.process_view().
If this would have worked as expected, the documentation should say
something like "After a login, the client needs to update the CSRF one
more time to keep posting in further requests - you may return it in your
login view to save one request", which applies to all logins - as you
said.
In this case, as it is overridden, there is no need, because the view
would be executed anyway and the data procesed - though without the
rotate_token() protection.
A fix for this that comes into my mind would be a "hook" on login to
deffer the token rotation and set a "user_has_logged" flag if REMOTE_USER
is enabled and then catch it later - as you said - to trigger the
rotation. This way it would behave as other backends.
Otherwise, it should be documented that token rotation on login is not
functioning for the REMOTE_USER backend, so beware! :)
--
Ticket URL: <https://code.djangoproject.com/ticket/28699#comment:23>
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.0565c48f5365b0081df03e28e8de2594%40djangoproject.com.
