I have a Django back end and a Vue front end. The front end runs on http://127.0.0.1:8080. When I make a post request to an end point I get the error
CSRF verification failed. Request aborted.
My settings are like this:
ALLOWED_HOSTS = ["*"]
CORS_ALLOWED_ORIGINS = ["http://localhost:8080", "http://127.0.0.1:8080"]
CORS_ORIGIN_WHITELIST = (
'localhost:8080',
'localhost:8081',
'localhost',
'localhost:8888',
)
CSRF_TRUSTED_ORIGINS = ['http://localhost:8080']
How does it work do I get the cookie from the back end or what? I know in a normal Django website you add a directive to a form and then that creates the cookie on the browser side but how does it work with a React or Vue app?
Any help is appreciated
Thanks
Start with reviewing the docs at Using CSRF protection with AJAX.
Hi Ken
Thanks but that’s not going to work as the Vue app is completely separate from the Django app so on the browser window where the Vue app runs on, there are no cookies so I cannot get the cookie to include it in the headers of the Vue app.
That is what I thought the settings below are for?
CSRF_TRUSTED_ORIGINS
CORS_ALLOWED_ORIGINS
CORS_ORIGIN_WHITELIST
This really isn’t relevent. From Django’s perspective, all requests “look” the same. All responses are effectively the same structure as well. It doesn’t matter what is making those requests.
If you are getting data from a CSRF-protected view in Django, Django should be sending that cookie to you in its response.
Examine the response you get from Django using your browser’s developer tools to verify that the cookie is present.
I added @csrf_protect and no cookie so Django is not sending the cookie to the browser for me to read.
The error page says this:
If you are not using CsrfViewMiddleware, then you must use csrf_protect on any views that use the csrf_token template tag, as well as those that accept the POST data.
I have that middleware in the settings so no need for me to use @csrf_protect but either way my post request to the endpoint gives me the same CSRF verification failed. Request aborted. error
This the response:
What specifically do you mean by this?
As the docs say, if you’re using the CsrfViewMiddleware, you don’t need to use the csrf_protect decorator.
It’s the CsrfViewMiddleware that adds the cookie to the response. If you have CsrfViewMiddleware defined in your settings and you’re not getting the cookie, you’ve got something else wrong.
What are you looking at to determine this?
Also, did you read Protecting a page that uses AJAX without an html form? It’s on the page referenced above.
Note: You do have to do at least one GET before your POST in order for the server to give you the cookie before you can turn around and submit it.
I added the decorator @csrf_protect to the login view and when I sent the request I see no cookie in browser developer tools the storage tab and under Cookies
I am trying to log a user in and I cannot make a get response first because what what am I supposed to get? Do I have to get the csrf cookie first using a get a request and then I can do a post request?
Here is my view:
@ensure_csrf_cookie
def LoginUser(request):
useremail = request.POST.get('email')
userpassword = request.POST.get('password')
user = authenticate(email=useremail, password=userpassword)
if user:
token = login_token
return HttpResponse(token)
else:
return HttpResponse(False)
But it doesn’t help me because I am sending the post before I get a response and I need the cookie before sending the response. That is why I want to know what is the purpose then of these settings:
CSRF_TRUSTED_ORIGINS
CORS_ALLOWED_ORIGINS
CORS_ORIGIN_WHITELIST
Aren’t they supposed to exempt applications who’s domains are mentioned in the lists?
Exempt? No. That’s not what the documentation for those settings say.
You can get any page that is not excluded from csrf protection and won’t throw an error if retrieved by an unauthenticated user. I’ve done this with a simple view that returns a simple “ok” as a JsonResponse. It doesn’t need to be anything special.
Ok then I am understanding it completely wrong cause the docs say this:
CSRF_TRUSTED_ORIGINS ¶
Default: [] (Empty list)
A list of trusted origins for unsafe requests (e.g. POST).
For requests that include the Origin header, Django’s CSRF protection requires that header match the origin present in the Host header.
So according to that it should not complain if I make a post request without a csrf cookie, yet it does.
Can I ask this: Does the order of the settings in the settings.py file matter? Can one setting maybe mess things up for another setting?
This makes no sense!!
No it does not say that.
The only thing it’s saying is that if you submit data with a POST, the protection scheme is going to require that the Origin header matches one of the entries in this list. This is in addition to having a matching CSRF token, not instead of.
I would think having a setting to exclude applications making requests from the same domain should be excluded from CSRF checks is a must. Any case I read on stackoverflow of several ways to first get the token and then adding it to the header of every request so I am going to try that.
I used djoser and that doesn’t require you to get the token first. It just works, so I wonder how they do it. But it’s not what I want and need a custom solution.
Thank you for the help much appreciated
Start with reading: How it works
Then please explain precisely what you mean by “applications making requests from the same domain”.
Now, regarding DRF / djoser, it’s a different situation.
From the docs at Authentication - Django REST framework
CSRF validation in REST framework works slightly differently from standard Django due to the need to support both session and non-session based authentication to the same views. This means that only authenticated requests require CSRF tokens, and anonymous requests may be sent without CSRF tokens. This behaviour is not suitable for login views, which should always have CSRF validation applied.
[Emphasis added]
Sorry I got it all wrong. I am using DRF and read how it works so I understand it better thanks.
