问题
My app worked well so far, when all was done by accessing its public IP.
Now, it's being added to the main site, as app.mainsite.com. It's accessible like that. I can log in, etc, everything.
But my app is a little special in that, a certain feature of it allows its users to open one of its URLs in an iframe on any third party site where the app's scripts are embedded in html, to do some app specific activity on those third party sites. Now, everyone could see the new stuff the app brought to those third party sites, but to change some settings as to how, one had to be logged in to my app. If not, one would be redirected inside the modal itself, and if login was successful, they'd be redirected to the settings edit page. Basically, any write requests from the third party sites, required the site owner to be logged in to our app. Either they could login inside the modal, or log in from another tab, and then refresh their site to be able to get inside the edit view.
The problem is, earlier, it all worked perfectly.
Now, I can do form post with csrf tokens from app.mainsite.com, but when it's opened in the iframe, it throws CSRF cookie not set.
I checked the Resources tab, and under that, the csrftoken in app.mainsite.com does not match the csrfmiddlewaretoken in the form.
Obviously thus, CSRF fails.
How can I overcome this?
I tried setting CSRF_COOKIE_DOMAIN='.mainsite.com' but that didn't work.
What can I do?
回答1:
you could try adding @csrf_exempt decorator around the view that serves the response... but of course, this will disable CSRF verification...
from django.views.decorators.csrf import csrf_exempt
@csrf_exempt
def your_view(request):
...
回答2:
Turned out, it was a bug in the Ubuntu build of Chromium. Yeah, I was using Chromium (and I use Ubuntu as my OS) That plnkr link that person provided in the issue, it didn't work in Chromium. But it worked fine in Chrome and Firefox
Tested my app too in Chrome and Firefox; works just as it did before.
来源：https://stackoverflow.com/questions/29559000/django-csrf-cookie-not-set-for-sub-domain-when-accessed-in-iframe-on-third-party