Authentication Ordering - Token vs Session

[Brad Erickson]

The ordering of the DEFAULT_AUTHENTICATION_CLASSES list matters. I'm using
DRF admin and the Chrome Postman app to test my API. When
SessionAuthentication is listed first and my browser is logged in the
Django admin, Token calls to the API fail with:

"detail": "CSRF Failed: CSRF token missing or incorrect."
According to the docs, if Session fails it should pass to the next
authentication system. DRF works as expected when setup like this:
REST_FRAMEWORK = {
'DEFAULT_AUTHENTICATION_CLASSES': (
'rest_framework.authentication.TokenAuthentication',
'rest_framework.authentication.SessionAuthentication',
),

Session must be listed last. It should be mentioned in the docs or maybe
code needs changing? Should this be a github issue?

[Tom Christie]

This will probably be due to using an in-browser API client.
I assume that it's including the session data in the cookies, which is why
the CSRF validation is being triggered.
Try making the same request from a non-browser API client and (I think) you
should see the issue resolve itself.

Post by Brad Erickson
The ordering of the DEFAULT_AUTHENTICATION_CLASSES list matters. I'm using
DRF admin and the Chrome Postman app to test my API. When
SessionAuthentication is listed first and my browser is logged in the
"detail": "CSRF Failed: CSRF token missing or incorrect."
According to the docs, if Session fails it should pass to the next
REST_FRAMEWORK = {
'DEFAULT_AUTHENTICATION_CLASSES': (
'rest_framework.authentication.TokenAuthentication',
'rest_framework.authentication.SessionAuthentication',
),
Session must be listed last. It should be mentioned in the docs or maybe
code needs changing? Should this be a github issue?

[Brad Erickson]

Yes, it is because of the in-browser API Client is including session
cookies. I mention it, because the failure goes against the documented
functionality IMO.

The authentication schemes are always defined as a list of classes. REST

framework will attempt to authenticate with *each class in the list*, and
will set request.user and request.auth using the return value of the
first class that successfully authenticates.

The above is not true when SessionAuthentication is listed first with the
browser API client edge case. SessionAuthentication fails with the CSRF
error which exits the authentication code skipping TokenAuthentication (and
any other authentication methods.) If SessionAuthentication is listed last,
then authentication works as documented.

This will probably be due to using an in-browser API client.
I assume that it's including the session data in the cookies, which is why
the CSRF validation is being triggered.
Try making the same request from a non-browser API client and (I think)
you should see the issue resolve itself.

Post by Brad Erickson
The ordering of the DEFAULT_AUTHENTICATION_CLASSES list matters. I'm
using DRF admin and the Chrome Postman app to test my API. When
SessionAuthentication is listed first and my browser is logged in the
"detail": "CSRF Failed: CSRF token missing or incorrect."
According to the docs, if Session fails it should pass to the next
REST_FRAMEWORK = {
'DEFAULT_AUTHENTICATION_CLASSES': (
'rest_framework.authentication.TokenAuthentication',
'rest_framework.authentication.SessionAuthentication',
),
Session must be listed last. It should be mentioned in the docs or maybe
code needs changing? Should this be a github issue?

[Tom Christie]

Totally possible that we should try to document this a little better, tho the behavior does make sense. The SessionAtuh bailing out early is essentially the same thing you'd see if token auth was first and the request included a malformed or incorrect token. In each case authentication *has* been attempted with the first possible class., and in each case it's (probably) better to fail loudly than to let the error pass. Open to change on any of this tho'.