starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Not respecting UPTIME_KUMA_DISABLE_FRAME_SAMEORIGIN=1 #1668

New issue

Closed

opened 2026-02-28 02:28:55 -05:00 by deekerman · 6 comments

deekerman commented

2026-02-28 02:28:55 -05:00

Owner

Originally created by @Leah96xxx on GitHub (Dec 23, 2022).

⚠️ Please verify that this bug has NOT been raised before.

I checked and didn't find similar issue

🛡️ Security Policy

I agree to have read this project Security Policy

Description

When launching Uptime Kuma from docker compose, it is not respecting UPTIME_KUMA_DISABLE_FRAME_SAMEORIGIN=1

I have tried using both 1 and true, but it ignores both, still showing "Refused to display 'https://kuma.[mydomain]' in a frame because it set 'X-Frame-Options' to 'sameorigin'." in the Chrome console.

Here is what I have in my docker-compose.yml:

uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    volumes:
      - /home/leah/docker/uptime-kuma:/app/data
    ports:
      - 3001:3001
    environment:
      - UPTIME_KUMA_DISABLE_FRAME_SAMEORIGIN=1
    restart: always

👟 Reproduction steps

Launch Uptime Kuma as described above, check if iframe works, find error in console

👀 Expected behavior

iframe works

😓 Actual Behavior

Iframe refuses to connect and Chrome console reports "Refused to display 'https://kuma.[mydomain]' in a frame because it set 'X-Frame-Options' to 'sameorigin'."

🐻 Uptime-Kuma Version

1.18.5

💻 Operating System and Arch

Raspberry PI OS Lite 11 (bullseye), RasPI 4 ARM v8

🌐 Browser

Google Chrome 108.0.5359.125

🐋 Docker Version

Docker 20.10.18

🟩 NodeJS Version

No response

📝 Relevant log output

No response

Originally created by @Leah96xxx on GitHub (Dec 23, 2022). ### ⚠️ Please verify that this bug has NOT been raised before. - [X] I checked and didn't find similar issue ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### Description When launching Uptime Kuma from docker compose, it is not respecting UPTIME_KUMA_DISABLE_FRAME_SAMEORIGIN=1 I have tried using both 1 and true, but it ignores both, still showing "Refused to display 'https://kuma.[mydomain]' in a frame because it set 'X-Frame-Options' to 'sameorigin'." in the Chrome console. Here is what I have in my docker-compose.yml: ``` uptime-kuma: image: louislam/uptime-kuma:1 container_name: uptime-kuma volumes: - /home/leah/docker/uptime-kuma:/app/data ports: - 3001:3001 environment: - UPTIME_KUMA_DISABLE_FRAME_SAMEORIGIN=1 restart: always ``` ### 👟 Reproduction steps Launch Uptime Kuma as described above, check if iframe works, find error in console ### 👀 Expected behavior iframe works ### 😓 Actual Behavior Iframe refuses to connect and Chrome console reports "Refused to display 'https://kuma.[mydomain]' in a frame because it set 'X-Frame-Options' to 'sameorigin'." ### 🐻 Uptime-Kuma Version 1.18.5 ### 💻 Operating System and Arch Raspberry PI OS Lite 11 (bullseye), RasPI 4 ARM v8 ### 🌐 Browser Google Chrome 108.0.5359.125 ### 🐋 Docker Version Docker 20.10.18 ### 🟩 NodeJS Version _No response_ ### 📝 Relevant log output _No response_

deekerman

2026-02-28 02:28:55 -05:00

closed this issue
added the
bug
label

deekerman commented

2026-02-28 02:29:01 -05:00

Author

Owner

@Leah96xxx commented on GitHub (Dec 23, 2022):

Ok, it somehow fixed itself. I have no clue what I did to fix it, but it now works in the iframe no problem.

@Leah96xxx commented on GitHub (Dec 23, 2022): Ok, it somehow fixed itself. I have no clue what I did to fix it, but it now works in the iframe no problem.

deekerman commented

2026-02-28 02:29:02 -05:00

Author

Owner

@DonovanDiamond commented on GitHub (Jan 19, 2023):

If this occurs to anyone, please ensure you do docker compose down and docker compose up to load the new environment variable.

@DonovanDiamond commented on GitHub (Jan 19, 2023): If this occurs to anyone, please ensure you do `docker compose down` and `docker compose up` to load the new environment variable.

deekerman commented

2026-02-28 02:29:02 -05:00

Author

Owner

@avishj commented on GitHub (Aug 14, 2023):

I ran into this same bug. I verified that the container is respecting the env flag, tried other browsers, chrome & firefox work properly, only edge doesn't work, any clues to what in edge's config would cause this?

Edit: Searched a bit more into this specific issue and running the html file that embeds the iframe via Live Server on VSCode works on Edge, but if I return that HTML page via a SpringBoot application running on a docker container and then try loading the HTML page on Edge, it no longer works. Not able to pin point what could be at fault here.

Edit #2: Nevermind, this fixed itself automatically after I changed some stuff related to the width and height of the iframe. I presume it definitely has nothing to do with the CSS changes but to do with the rm -f of the container and then rerunning the application serving the HTML, but then what surprises me here is that I have done this rm -f and run about 6-7 times previously and none of those fixed this weird issue. Maybe some sort of cache?

@avishj commented on GitHub (Aug 14, 2023): I ran into this same bug. I verified that the container is respecting the env flag, tried other browsers, chrome & firefox work properly, only edge doesn't work, any clues to what in edge's config would cause this? Edit: Searched a bit more into this specific issue and running the html file that embeds the iframe via Live Server on VSCode works on Edge, but if I return that HTML page via a SpringBoot application running on a docker container and then try loading the HTML page on Edge, it no longer works. Not able to pin point what could be at fault here. Edit #2: Nevermind, this fixed itself automatically after I changed some stuff related to the width and height of the iframe. I presume it definitely has nothing to do with the CSS changes but to do with the rm -f of the container and then rerunning the application serving the HTML, but then what surprises me here is that I have done this rm -f and run about 6-7 times previously and none of those fixed this weird issue. Maybe some sort of cache?

deekerman commented

2026-02-28 02:29:02 -05:00

Author

Owner

@gamer50082 commented on GitHub (Nov 14, 2023):

same issue but i dont use docker so how to fix

@gamer50082 commented on GitHub (Nov 14, 2023): same issue but i dont use docker so how to fix

deekerman commented

2026-02-28 02:29:02 -05:00

Author

Owner

@chakflying commented on GitHub (Nov 15, 2023):

It's an environment variable. How you set the environment variable depends on your OS and how you start the application.

@chakflying commented on GitHub (Nov 15, 2023): It's an environment variable. How you set the environment variable depends on your OS and how you start the application.

deekerman commented

2026-02-28 02:29:02 -05:00

Author

Owner

@karolysaysbye commented on GitHub (Apr 16, 2024):

Solution on Edge: Ctrl+ F5 or delete cookies and will be fine (you can also check in edge private mode first)
Ctrl+F5 will force the browser to retrieve the webpage from the server instead of loading it from the cache

@karolysaysbye commented on GitHub (Apr 16, 2024): **Solution on Edge:** Ctrl+ F5 or delete cookies and will be fine (you can also check in edge private mode first) Ctrl+F5 will force the browser to retrieve the webpage from the server instead of loading it from the cache