starred/uptime-kuma

Fork 0

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

simplify public exposure vs authenticated ressources #1489

New issue

Open

opened 2026-02-28 02:23:02 -05:00 by deekerman · 4 comments

deekerman commented

2026-02-28 02:23:02 -05:00

Owner

Originally created by @ka2er on GitHub (Oct 17, 2022).

⚠️ Please verify that this feature request has NOT been suggested before.

I checked and didn't find similar feature request

🏷️ Feature Request Type

Other

🔖 Feature description

When I expose uptime-kuma via cloudflare tunnel access I could put an auth wall in front of uptime kuma.
What I try to achieve is to have admin part (all except status page /status/*) behind cloudflare auth (ok), but put status page behind cloudflare WITHOUT auth (policy = bypass for /status path).

The problem is that /status page rely on ressources that are on root path like :

/assets/
/api/status-page/

✔️ Solution

put all resources that could be public exposed without security concerns under a public subfolder like /public in order to easy reverse proxying.

❓ Alternatives

adding all sub ressources to a new cloudflare tunnel application but I'm concern about :

security issues by exposing api that could allow more than needed
it may be difficult to maintain if new ressources are added in other path

📝 Additional Context

No response

Originally created by @ka2er on GitHub (Oct 17, 2022). ### ⚠️ Please verify that this feature request has NOT been suggested before. - [X] I checked and didn't find similar feature request ### 🏷️ Feature Request Type Other ### 🔖 Feature description When I expose uptime-kuma via cloudflare tunnel access I could put an auth wall in front of uptime kuma. What I try to achieve is to have admin part (all except status page /status/*) behind cloudflare auth (ok), but put status page behind cloudflare *WITHOUT* auth (policy = bypass for /status path). The problem is that /status page rely on ressources that are on root path like : - /assets/ - /api/status-page/ ### ✔️ Solution put all resources that could be public exposed without security concerns under a public subfolder like /public in order to easy reverse proxying. ### ❓ Alternatives adding all sub ressources to a new cloudflare tunnel application but I'm concern about : - security issues by exposing api that could allow more than needed - it may be difficult to maintain if new ressources are added in other path ### 📝 Additional Context _No response_

deekerman added the

feature-request

A:core

security

labels

2026-02-28 02:23:02 -05:00

deekerman commented

2026-02-28 02:23:05 -05:00

Author

Owner

@DusterTheFirst commented on GitHub (Nov 15, 2022):

This would be extremely useful for public-facing status-page. Right now, there is no difference from a status-page and the dashboard authentication wise. You can authenticate on the public facing status pages, and if we set a domain name, you can even access the dashboard from that domain, which would be unwanted for security reasons. I think being able to whitelist known, read-only apis and safe client side assets would be very useful for running uptime-kuma behind a reverse proxy and adding extra authentication or security in front of the admin side while leaving the status-pages public.

@DusterTheFirst commented on GitHub (Nov 15, 2022): This would be extremely useful for public-facing status-page. Right now, there is no difference from a status-page and the dashboard authentication wise. You can authenticate on the public facing status pages, and if we set a domain name, you can even access the dashboard from that domain, which would be unwanted for security reasons. I think being able to whitelist known, read-only apis and safe client side assets would be very useful for running uptime-kuma behind a reverse proxy and adding extra authentication or security in front of the admin side while leaving the status-pages public.

deekerman commented

2026-02-28 02:23:05 -05:00

Author

Owner

@rdbahm commented on GitHub (Jan 6, 2023):

+1 to this issue.

If it's helpful, I was able to find a useful way to secure this somewhat: The dashboard requires Websockets to function, while the status pages do not. You can limit access on status pages by having a separate reverse proxy configuration for them with websockets disabled. I also configured NGINX to prohibit anything but "GET" on the API endpoints for status pages.

@rdbahm commented on GitHub (Jan 6, 2023): +1 to this issue. If it's helpful, I was able to find a useful way to secure this somewhat: The dashboard requires Websockets to function, while the status pages do not. You can limit access on status pages by having a separate reverse proxy configuration for them with websockets disabled. I also configured NGINX to prohibit anything but "GET" on the API endpoints for status pages.

deekerman commented

2026-02-28 02:23:05 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Dec 7, 2023):

Related #2505

@CommanderStorm commented on GitHub (Dec 7, 2023): Related #2505

deekerman commented

2026-02-28 02:23:05 -05:00

Author

Owner

@CompeyDev commented on GitHub (Feb 27, 2025):

This would be useful! I spent quite a bit with Traefik trying to reverse proxy such that one domain has the status page, and the other has the dashboard.

However, the status page domain always redirects back to the dashboard because I have to pass /assets/ through to the dashboard's router, which returns a JS module that fetches an /api/ route to get what the route it should redirect to. With Nginx, I believe you could rewrite what the API route returns for the status page router to return something favorable, but that is not possible with Traefik. I think this would be possible though, if what this issue demands was implemented.

@CompeyDev commented on GitHub (Feb 27, 2025): This would be useful! I spent quite a bit with Traefik trying to reverse proxy such that one domain has the status page, and the other has the dashboard. However, the status page domain always redirects back to the dashboard because I have to pass `/assets/` through to the dashboard's router, which returns a JS module that fetches an `/api/` route to get what the route it should redirect to. With Nginx, I believe you could rewrite what the API route returns for the status page router to return something favorable, but that is not possible with Traefik. I think this would be possible though, if what this issue demands was implemented.