CSRF verification failed. Request aborted - Shopping cart configuration - django

I'm trying to enable Payment module for courses and when I'm clicking checkout, I'm getting "CSRF verification failed. Request aborted." . I've tried adding my domain to "Home › Cors_Csrf › X domain proxy configurations › XDomainProxyConfiguration()" in Django admin panel. Even modified lms.env.json to add "ENABLE_CROSS_DOMAIN_CSRF_COOKIE": true, " ... still facing the issue. Can anyone please help.
Google group message link : https://groups.google.com/d/msg/edx-code/4VnLJG-raPE/llF1PDG9AQAJ

Possibly you're not including the CSRF token in your form. In your template, it should look like:
<form action="post">
{% csrf_token %}
{{form.as_p}}
</form>
I don't know the library you're using, that was just general Django commentary. Hopefully it's helpful.

Related

Forbidden (403) CSRF verification failed - Error with Docker, Django and Nginx

I am new to docker. Starting from a Django project (Django 4.0), I am using Docker to side by side with Nginx.
I used a docker-compose.yml file and used a custom configuration of Nginx, and everything works.
Only when I go to the login screen and click the "Login" button it comes up "Forbidden (403) CSRF verification failed. Request aborted.".
The code inside login.html is like this
<form method="post">{% csrf_token %}
{{ form|crispy }}
<button class="btn btn-success ml-2" type="submit">Log In</button>
Thanks in advance!
I would recommend you to read through all of these settings starting with "CSRF_" here
As you did not provide your settings.py I can only guess that the problem lays in there. Your form template is fine.
Probably my link leads you already to the correct setting, called CSRF_TRUSTED_ORIGINS where you basically input all your domains that you want to trust as a list. (Trust meaning which domain is allowed to send a post request)
settings.py:
CSRF_TRUSTED_ORIGINS = [
'https://trusted.domain.one.com',
'https://trusted.domain.two.com'
]
If this does not work try also to add the 'http://trusted.domain.one.com' without the S in httpS.

CSRF 403 in default Django login

I'm fairly new to Django. Here's what I need insight on:
After updating from Django 3 to 4:
On the local dev server, no issue.
On production: CSRF 403 error on login.
There's a cookie loaded on the login page containing
csrftoken: pAFeeUI8YFXZ2PKRYxOTX1qz4Xgto42WVNi7FFvBlZDqcFLwQ2rdQvVeZBHFSpLW
(Local and Session storage are empty)
In the FORM element:
<input type="hidden" name="csrfmiddlewaretoken" value="Vz4FiujD4qkLpxCwWNJU0HCWs4u0Qf4RrMHyJf66rK0cznDbOimeTb7BnIVckANR">
Notice they don't match.
I tried manually deleting the cookie and also running ./migrate.py clearsessions.
The first time, yesterday, it seemed that the error did not occur in an Incognito Window, but today it persists even in an incognito window, as well as a different browser.
One additional piece of information
allauth had been previously installed, but was causing infinite redirect loop on login, so removed. The login page url is /login/?next=/.
Thanks much.
At least in Django 4.0, you can–and possibly must–specify CSRF trusted origins in your settings.py file:
CSRF_TRUSTED_ORIGINS = ["https://yourdomain.com", "https://www.yourdomain.com"]
Note www and non-www as well as no trailing /.
At any rate, it solved the issue for me.
See Docs.
You should add {% csrf_token %}:
{% csrf_token %}
<input type="hidden" name="csrfmiddlewaretoken" value="Vz4FiujD4qkLpxCwWNJU0HCWs4u0Qf4RrMHyJf66rK0cznDbOimeTb7BnIVckANR">

Prevent form resubmission with user refresh and need to submit data to webpage using Django

I've seen this question a few times and can't find an option that works in my situation.
I have a webpage that you can get to via a POST. It requires an 'example_id' be sent to the server.
The webpage has a form for the user to fill out. When they submit the form, I need the user to return to same page.
I need to prevent user 'refresh' from resubmitting the form. Most common solution I have found is:
return HttpResponseRedirect('/<web_page/')
I have tried this and adding kargs to the function parameters, but it doesn't seem to work.
Update:
I got my scenario to work by using the csrf token ({% csrf_token %}) . If the user refreshes the page, then the csrf token will be the same. So I check for this in my view and handle this scenario differently.
The solution I found.
I got my scenario to work by using the csrf token: {% csrf_token %}
If the user refreshes the page, then the csrf token will be the same. So I check for this in my view and handle this scenario differently than I would normally.

Django clickjacking middleware and Firefox embedded PDFs

I recently added clickjacking protection to a Django app with django.middleware.clickjacking.XFrameOptionsMiddleware but found that PDFs no longer load in Firefox. While Chrome, Safari, and Edge embed the PDF as expected, Firefox throws the following console error:
Load denied by X-Frame-Options: <site_base>/<file_path>.pdf does not permit framing.
I found the #xframe_options_exempt decorator that I thought would help, but that just wraps a view whereas these are served directly through Apache. The only fix I've found is to get the "Ignore X-Frame-Options Header" browser plugin which isn't really a customer friendly solution.
I've tried using <embed>, <object>, and <iframe> to embed the PDF and all cause the same browser console error, and if I remove the clickjacking middleware the PDFs load just fine again.
Anyone run into something like this before? Relevant code:
<select id="pdf_graph_selection" onchange="updatePDF()">
{% for pdf_graph in pdf_graphs %}
<option value="{{pdf_graph.url"}}>{{pdf_graph.name}}</option>
{% endfor %}
</select>
<div id="pdf_container"></div>
function updatePDF() {
let new_source = $("#pdf_graph_selection").val();
let new_graph = "'<embed src='" + new_source + "' width='70%' height='900px' class='pdf_embed'></embed>;
$("#pdf_container").html(new_graph);
}
My coworker was able to help figure it out - We had a custom file response handler that must have been doing something Firefox didn't like. By adding the #xframe_options_sameorigin decorator it is now working.

CRSF cookie not set in iframed Django View within another site

I have a Django app with about a dozen views that I am currently hosting on Heroku. I can do POST requests just fine to the app when directly going to the app url, and I have the 'django.middleware.csrf.CsrfViewMiddleware' enabled. I am running Django 2.1
I am currently having an issue where I am trying to embed this Django app within an iframe, on another site that I host on Weebly. I always get a 403 error when trying to do a post on any of the Django forms. The reason is "CSRF cookie not set."
I am doing this through Chrome on Ubuntu. I checked the Applications tab in the Developer console, and do see the csrftoken key-value pair set in the cookie for the Heroku domain. The Weebly domain does not contain the csrftoken key-value pair. I figured it would just use the cookie from the Heroku app domain and use the csrftoken, but that doesn't appear to be the case.
In Django, here are my settings regarding CSRF:
CSRF_COOKIE_SECURE = False
CSRF_TRUSTED_ORIGINS = ['example123.herokuapp.com',
'app123.weebly.com']
I REALLY don't want to disable security or use the csrf_exempt decorator, as that feels like a hack. I am pulling my hair out on this one!
EDIT:
{% csrf_token %} is in the form, and I can see the hidden field "csrfmiddlewaretoken":
<input type="hidden" name="csrfmiddlewaretoken" value="XXXXXXXXXXXXXXXXXXXXXXywkFTfTC9ttYiOTD0O8uF49SvRjaUWgWeLU0h2PjP2">
There are two different things with csrf in django
1. Csrfmiddlewaretoken : {% csrf_token %}
example of set-token header
2. CSRFcookie : I don't think that you did this one.
example of same request giving different csrf-token
here the images shown are both the examples of one of my app for a specific request
We do often confuse second with the first one. In the second case, the server sets a cookie in the first get request with a csrf token (this is a cookie and not the csrfmiddlewaretoken ), it needs to be sent every-time for csrf cookie verification. This is done by the browser itself and we mostly don't notice it. However the problem arises with using CORS (different origins of request like android/angular app etc).