[GH-ISSUE #326] CSRF for iframe #248

New issue

Closed

opened 2026-02-25 23:41:46 +03:00 by kerem · 2 comments

kerem commented

2026-02-25 23:41:46 +03:00

Owner

Originally created by @BobCashStory on GitHub (Feb 6, 2020).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/326

i need to be able to configure CSRF_COOKIE_DOMAIN from django, to allow my main domain like exemple.com .
Then make login in iframe work.
like healtcheck is healtcheck.exemple.com an iframed into main.exemple.com

Originally created by @BobCashStory on GitHub (Feb 6, 2020). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/326 i need to be able to configure CSRF_COOKIE_DOMAIN from django, to allow my main domain like exemple.com . Then make login in iframe work. like healtcheck is healtcheck.exemple.com an iframed into main.exemple.com

kerem closed this issue

2026-02-25 23:41:46 +03:00

kerem commented

2026-02-25 23:41:46 +03:00

Author

Owner

@cuu508 commented on GitHub (Mar 4, 2020):

I'd like to understand the problem a little better.

A. Is the login form served on a different domain? I.e., you have a centralized login form which takes username and password, and submits it to a Healthchecks instance running somewhere else?

This would try to do exactly what CSRF protection is supposed to prevent. So CSRF protection would have to be switched off. A better solution would be to look into implementing some form of SSO.

B. Or is the login form still served by Healthchecks, but everything is enclosed in an iframe, in order to add a custom header or footer?

With some hacks this can work:

Comment out django.middleware.clickjacking.XFrameOptionsMiddleware
Add CSRF_COOKIE_SAMESITE = None
Add SESSION_COOKIE_SAMESITE = None

But the user experience would be pretty bad: cannot see the URL in address bar, cannot bookmark pages, cannot link directly to check details pages, potential double vertical scrollbars. If you need custom header/footer it would be better to edit the base template.

@cuu508 commented on GitHub (Mar 4, 2020): I'd like to understand the problem a little better. A. Is the login form served on a different domain? I.e., you have a centralized login form which takes username and password, and submits it to a Healthchecks instance running somewhere else? This would try to do exactly what CSRF protection is supposed to prevent. So CSRF protection would have to be switched off. A better solution would be to look into implementing some form of SSO. B. Or is the login form still served by Healthchecks, but everything is enclosed in an iframe, in order to add a custom header or footer? With some hacks this can work: * Comment out `django.middleware.clickjacking.XFrameOptionsMiddleware` * Add `CSRF_COOKIE_SAMESITE = None` * Add `SESSION_COOKIE_SAMESITE = None` But the user experience would be pretty bad: cannot see the URL in address bar, cannot bookmark pages, cannot link directly to check details pages, potential double vertical scrollbars. If you need custom header/footer it would be better to edit the base template.

kerem commented

2026-02-25 23:41:46 +03:00

Author

Owner

@BobCashStory commented on GitHub (Mar 4, 2020):

B. the login form still served by Healthchecks !

But in fact the last update you made with the fix Don't set CSRF cookie on first visit. Signup is exempt from CSRF protection make it work for my side !
I though you fixed it because of my issue, ahah, thanks :)

@BobCashStory commented on GitHub (Mar 4, 2020): B. the login form still served by Healthchecks ! But in fact the last update you made with the fix Don't set CSRF cookie on first visit. Signup is exempt from CSRF protection make it work for my side ! I though you fixed it because of my issue, ahah, thanks :)

kerem referenced this issue

2026-02-25 23:44:09 +03:00

[PR #248] [MERGED] Updated Build instructions #922