CSRF error when using rest_framework.authtoken.views.obtain_auth_token

5,223 views
Skip to first unread message

Nigel Daniels

unread,
Jun 14, 2013, 10:09:50 PM6/14/13
to django-res...@googlegroups.com

I am calling obtain.auth_token from urls as follows

url(r'^api-token/','rest_framework.authtoken.views.obtain_auth_token')

I get back

{
detail: "CSRF Failed: CSRF token missing or incorrect."
}

I am wondering why this happens as I was under the impression django-rest-framework was usually CSRF exempt

Thanks


Nigel Daniels

unread,
Jun 19, 2013, 12:49:35 AM6/19/13
to django-res...@googlegroups.com
kinda surprised no one has an answer.

Tom Christie

unread,
Jun 19, 2013, 3:56:14 AM6/19/13
to django-res...@googlegroups.com
I am wondering why this happens as I was under the impression django-rest-framework was usually CSRF exempt

To clarify, session authenticated requests are CSRF protected, all other requests are not.
What this means is:

* Requests that are authenticated via session auth (ie. There is a logged in user making a request) require CSRF protection.
* Requests that are authenticated via non-session auth (eg. TokenAuthentication) do not require CSRF proection.
* Anonymous requests do not require CSRF protection.

The only reason you should be getting a CSRF failure is if you're making the request as a logged in user.

Of course if you've got a logged in session, you shouldn't need to be calling obtain_auth_token, because all your requests will already be authenticated.  Normally this case is where the API client is javascript making AJAX requests, and running in the context of a session that the user has logged into your app.  You *could* still call obtain_auth_token, which might make sense perhaps if this is part of a front end that's handing out tokens to the developer (rather than handing them to be used by the client app), tho you would need to include the CSRF token in the request, as described in the Django docs.

So, question - what client are you using to make the requests?  If you don't believe that the behavior is correct (eg you don't believe the requests are being made by a logged in user) then what is the simplest way someone could replicate the behavior (eg what exact commands are you running the client with).

I hope this helps explain adequately, it's a difficult area to document and describe well - let us know what resolution you reach, or if this remains an issue that needs further attention.

All the best,

  Tom

Nigel Daniels

unread,
Jun 22, 2013, 2:12:25 AM6/22/13
to django-res...@googlegroups.com
So I was using the chrome  advanced rest client to make the request. 
simply specifying a username and password in a post request like whats described in the docs 

the content of my post request is as fallows

username=mytestuser%40gmail.com&password=somepassword

I went back and re-tested 

when testing it with a user that was not logged in I get the CSRF error I stated earlier 

backe...@miv.uk.com

unread,
Jun 24, 2013, 5:08:08 AM6/24/13
to django-res...@googlegroups.com
That thing happened to me a lot of times.
The reason is because you are loged in chrome after being playing with the web interface and then you are trying to receive a token from advance rest client.
Deleting cookies should solve the problem, what I do if using a Incognito Window for the web interface.

Val Neekman

unread,
Nov 7, 2016, 7:30:52 PM11/7/16
to Django REST framework
IMHO if a client passes the credentials and has a valid token, then CSRF token should NOT be required.  The token is a sacred thing, if you have it, then you get what you are entitled to.

With the current behavior, one must either not log in through the same browser or delete the cookie which logs the user out anyways.

The workaround is use different browsers for testing the SPA and the django admin.

Tom Christie

unread,
Nov 8, 2016, 4:16:14 AM11/8/16
to Django REST framework
> If a client passes the credentials and has a valid token, then CSRF token should NOT be required. 

The CSRF token isn't required if you're authenticated using a different scheme.

> With the current behavior, one must either not log in through the same browser or delete the cookie which logs the user out anyways.

We don't currently have any mechanism for a user to be authenticated with the browsable API other than session authentication.

Reply all
Reply to author
Forward
0 new messages