How to expose main page (not a status page) without exposing admin/edit functions #4546

New issue

Closed

opened 2026-02-28 04:06:50 -05:00 by deekerman · 1 comment

deekerman commented

2026-02-28 04:06:50 -05:00

Owner

Originally created by @nneul on GitHub (Dec 23, 2025).

⚠️ Please verify that your question has not already been reported

I have searched the existing issues and found no similar reports.

🛡️ Security Policy

I have read and agree to Uptime Kuma's Security Policy.

📝 Describe your problem

I have UK sitting behind a reverse proxy to provide OIDC/SAML with the server set to no-auth. However, this limits to just administrator.

I'd really like to be able to expose the main dashboard - since that provides a nice simplistic overall view of all services in the hierarchy, however, it's my understanding that all of the control activities are running through the same websocket as is used for the display updates.

Is there any practical way to control methods/paths/etc. that would allow exposing the main dashboard view without exposing administrative internals? (Note, I don't care about cosmetics like broken 'Add New Monitor' button if certain dependent paths were blocked - I just want the information to be visible.)

I'd like to suggest a likely simple potential change that could make this possible -- split into two websockets. One for admin/edit/write/sensitive, the other for "view" UI functionality only.

Alternative implementation - though likely much more invasive: allow an internal config setting that says "For any write/admin/etc. activity, require that a specific header/value be present in the request." - such as X-Remote-User (such as mentioned in https://github.com/louislam/uptime-kuma/issues/146) - this could allow the frontend proxy to easily insert a "yes, this user is autenticated for admin purposes". Then any backend function that does admin functionality would check for "if flag and !found" before processing.

📝 Error Message(s) or Log

na

🐻 Uptime-Kuma Version

2.0

💻 Operating System and Arch

Deb 12 w/ Docker

🌐 Browser

Chrome, NA

🖥️ Deployment Environment

Runtime Environment:
- Docker behind an authenticating reverse proxy
Database:
- MariaDB: External
Database Storage:
- Filesystem:
  - Linux: ext4
- Storage Medium: SSD
Uptime Kuma Setup:
- Number of monitors: 40-50

Originally created by @nneul on GitHub (Dec 23, 2025). ### ⚠️ Please verify that your question has not already been reported - [x] I have searched the [existing issues](https://github.com/louislam/uptime-kuma/issues?q=is%3Aissue%20sort%3Acreated-desc%20) and found no similar reports. ### 🛡️ Security Policy - [x] I have read and agree to Uptime Kuma's [Security Policy](https://github.com/louislam/uptime-kuma/security/policy). ### 📝 Describe your problem I have UK sitting behind a reverse proxy to provide OIDC/SAML with the server set to no-auth. However, this limits to just administrator. I'd really like to be able to expose the main dashboard - since that provides a nice simplistic overall view of all services in the hierarchy, however, it's my understanding that all of the control activities are running through the same websocket as is used for the display updates. Is there any practical way to control methods/paths/etc. that would allow exposing the main dashboard view without exposing administrative internals? (Note, I don't care about cosmetics like broken 'Add New Monitor' button if certain dependent paths were blocked - I just want the information to be visible.) I'd like to suggest a likely simple potential change that could make this _possible_ -- split into two websockets. One for admin/edit/write/sensitive, the other for "view" UI functionality only. Alternative implementation - though likely much more invasive: allow an internal config setting that says "For any write/admin/etc. activity, require that a specific header/value be present in the request." - such as X-Remote-User (such as mentioned in https://github.com/louislam/uptime-kuma/issues/146) - this could allow the frontend proxy to easily insert a "yes, this user is autenticated for admin purposes". Then any backend function that does admin functionality would check for "if flag and !found" before processing. ### 📝 Error Message(s) or Log ```bash session na ``` ### 🐻 Uptime-Kuma Version 2.0 ### 💻 Operating System and Arch Deb 12 w/ Docker ### 🌐 Browser Chrome, NA ### 🖥️ Deployment Environment - **Runtime Environment**: - Docker behind an authenticating reverse proxy - **Database**: - MariaDB: External - **Database Storage**: - **Filesystem**: - Linux: ext4 - **Storage Medium**: SSD - **Uptime Kuma Setup**: - Number of monitors: `40-50`

deekerman

2026-02-28 04:06:50 -05:00

closed this issue
added the
help
label

deekerman commented

2026-02-28 04:06:56 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Dec 23, 2025):

This is not currently supported.
You likely can hack it together, but I don't want to give security-dangerous/wrong advice.

At the moment, Uptime Kuma does not have a distinction between “admin” and “non-admin” users. As a result, selectively exposing parts of the UI (such as a read-only dashboard) is not possible with the current architecture.

I’m also not inclined to pursue a multi-WebSocket approach here. Splitting functionality across multiple sockets would significantly increase complexity and introduces a large potential footgun from both a maintenance and security perspective.

Related and relevant efforts can be tracked in the following issues:

multi user -> #128
oidc -> #553
better auth (how to get there) ->#6200

We do intend to start working toward better authentication and authorization in the v3.0 timeframe, but engineering resources are currently quite limited.

If you’re interested in helping move this forward, contributions that help burn down the backlog toward that goal would be very much appreciated:

#6260

@CommanderStorm commented on GitHub (Dec 23, 2025): This is not currently supported. You likely can hack it together, but I don't want to give security-dangerous/wrong advice. At the moment, Uptime Kuma does not have a distinction between “admin” and “non-admin” users. As a result, selectively exposing parts of the UI (such as a read-only dashboard) is not possible with the current architecture. I’m also not inclined to pursue a multi-WebSocket approach here. Splitting functionality across multiple sockets would significantly increase complexity and introduces a large potential footgun from both a maintenance and security perspective. Related and relevant efforts can be tracked in the following issues: - multi user -> #128 - oidc -> #553 - better auth (how to get there) ->#6200 We do intend to start working toward better authentication and authorization in the v3.0 timeframe, but engineering resources are currently quite limited. If you’re interested in helping move this forward, contributions that help burn down the backlog toward that goal would be very much appreciated: - #6260