Allow basic User management without permissions

[Nicklas2751]

I host some services together with some friends, I'd like to let them add some Monitors but not to change the notification settings or change/delete monitors of others. To achieve this, it would be nice to have a small user management where I can create roles, set privileges for roles, create users and assign users to roles.

Additional: When I look at other feature requests like the one with the API, this could be a good base to create technical accounts which then are able to access the API with a generated API token or something like that.

[Zegorax]

In addition to that, an extension of this feature would be LDAP integration with group to permission mapping.

Overall, great project!

[jtagcat]

LDAP and other integrations could be easily done with the Remote-* headers:

• Remote-User (username, might be a GUID)
• Remote-Groups (groups the belong to)
• Remote-Name (display name)

Authelia is rising in popularity as an authentication layer, that can also use this.

[Cristy94]

This is a highly requested feature, are there any plans to implement it? Is it being considered?

[deefdragon]

This is a highly requested feature, are there any plans to implement it? Is it being considered?

There are at-least a few features that are currently being worked on that may interfere with this being tackled immediately (Settings page redesign and multiple status pages for example), and there are some other highly requested features that may be done first. (I personally want to work on notification options after the templates are finished for example.)

It IS being considered however (were it not louis would have closed it), but beyond the above, louis is slow to merge things sometimes because they get busy, and many of the contributors are focusing elsewhere at the moment.

I understand the want to have users. Allowing for users/ldap integration is likely one of the largest blocks behind this getting used in a business environment. Unfortunately, it is going to take some time. UK is < 6 months old, but already a great app. We will get users eventually, just not immediately.

[ugurerkan]

I could prepares basic steps and create a template PR for this feature.
AFAIK, there is already a base structure for multi user in Kuma.

[deefdragon]

@ugurerkan Pull requests are ALWAYS welcome. Feel free to tackle it.

[louislam]

I could prepares basic steps and create a template PR for this feature. AFAIK, there is already a base structure for multi user in Kuma.

Should leave this part to me. It is a super big feature. It is not as easy as you thought.

User management usually come with permission group and access control, which means a user may have or don't have a right to access other resources of users/groups.

Also as mentioned in another thread, there is only frontend input validation. Backend validation is missing.

[ugurerkan]

Sure, understand that. If you prefer design the structural guideline and move about sub-tasks or need support over chores kind operations I can gladly involve or try to contribute other requests as well 🤓

[CoolCoderSJ]

Hey there, I'm Snow, and I volunteer at Replit. Recently, our community has come to the realization that Uptimerobot, a popular uptime monitoring service that we redirect our users to to keep their projects alive, has stopped allowing repls, or projects on Replit, to be pinged for free.

I've personally been using Uptime Kuma for months, and I've always found it better than uptimerobot. Now that we're forced to look to new options, I look here.

Kuma is spectacular, but requires multi auth functionality to provide our users a better experience.

Would it be at all possible to move this issue to a higher priority, as I see it's been deserted for months.

If not, that's totally okay, we'll just look to other options.

[foliovision]

We need this @louislam

I notice you are a sponsor @acki Christopher, so "We need this" is a fair comment. Multi-user is a huge request though, almost as big as the rest of the project put together. It would be great if a war chest could be raised for this feature from those who need it (multiuser would elevate UptimeKuma to the level of the best commercial uptime monitoring tools). If there's enough backing then multiuser should go ahead. If not, it should not.

For our own use, as a small software development company with some VIP development clients, we've been happy with paid UptimeRobot (until they tripled their prices) without mutiuser. No one who is not an admin needs access. Anyone who is an admin knows not to mess with the monitors.

I recognise that larger organisations have different needs. Still, multiuser without adequate backing could slow UptimeKarma development and destroy the project.

[anthosz]

I notice you are a sponsor @acki Christopher, so "We need this" is a fair comment. Multi-user is a huge request though, almost as big as the rest of the project put together. It would be great if a war chest could be raised for this feature from those who need it (multiuser would elevate UptimeKuma to the level of the best commercial uptime monitoring tools). If there's enough backing then multiuser should go ahead. If not, it should not.

For our own use, as a small software development company with some VIP development clients, we've been happy with paid UptimeRobot (until they tripled their prices) without mutiuser. No one who is not an admin needs access. Anyone who is an admin knows not to mess with the monitors.

I recognise that larger organisations have different needs. Still, multiuser without adequate backing could slow UptimeKarma development and destroy the project.

+1, imo #118 seems more important than multi user

[ccoenen]

It would be great if a war chest could be raised for this feature from those who need it

Just as a precaution: please do not go with bountysource.

[hegerdes]

I personally have no preference whether uptime-kuma supports user management. But if this is the case I would like to offer to implement or support the implementation of the OIDC/OAUTH functionality tracked in #553 and #3328 (I don't really see are deference between them regarding implementation), at least as far as my time allows to.

Just some thoughts:
Theoretically, this could also be implemented now without real user management. Every logged-in user could then access and change the same state. However, I consider this problematic due to security-relevant settings and it would not be a future-proof solution if user management is added. So I'm not a fan of doing this before user-management with permissions is supported.

Another thing is that this adds complexity - quiet a bit. Oauth/OIDC is complicated and there are 1000s of small differences in implementation - most work, some don't. Testing this is also quiet hard since you cant really write meaningful unit tests. Just testing the major ones like Google and Microsoft is annoying as hell because you need to setup configuration on each provider.
I don't know wich user group uptime-kuma mainly wants to focus on, since Oauth/OIDC/SAML is often a business requirement. While it would be a nice to have for hobby users and small application scenarios it is bearable to use local accounts. In large companies this is a no-go.

[M1CK431]

Hi @hegerdes thanks for sharing your thoughts.

Theoretically, this could also be implemented now without real user management.

Agree, and it's the reason why adding auth providers is out of the scope of this feature request (because not mandatory to multi users)

However, I consider this problematic due to security-relevant settings

No worries, the only "security-relevant settings" (API token) is per user in my implementation (see #3571 for details).

In large companies this is a no-go

I'm not the owner of this project so this is only a personal opinion: if large companies wants to use this project and need a feature or another which is not (yet) implemented, they "just" have to contribute to the project to add it! After all, this is the open source spirit, right? 😉

So, at least for now, local accounts seems to me already a giant step forward. Let's do this first, it will still be time to add such complexity later.

[CommanderStorm]

I am going to lock the conversation on this thread, as the constant bumping (thus pinging many people without any content) is not helping to make this issue more managable/readable.
I don't think more needs to be said about this issue.
@slickware (sorry to single you out like this) The correct way to "bump" something is to add a 👍🏻 on issues and to only comment if value can be added. Posting +1 / requests for updates things on issues, makes issue-management a lot harder because they also require maintainer time.

The status of #128 (comment) has not changed, the PR #3571 has been slated for review.
I encourage you/everyone to do a review and note issues introduced by said PR via the command used to test PRs in the Pull request.

[chakflying]

I think a comment with a good description of use case with "why I really want this" is not meaningless. Historically we have not done any user survey, we don't have a discord etc. to capture user feedback and experiences. User comments here have been the sole metric of user attention and their needs. Upvotes are helpful, but they do not provide context or timeliness.

Realistically, #3571 is still months away from even being considered. Can't speak for others but for me, issues do get "forgotten" as real life or other ideas get in the way. A gentle reminder doesn't make things go faster, but it also doesn't hurt.

Locking a thread is a big hammer, and I don't think it should be struck lightly. Maybe you don't like clicking on a notification to see no actionable content, but in general, I think tolerating a reasonable amount of "noise" (that is not pure spam) is a sign of a healthy community, and is valuable given how the project is run currently.

[CommanderStorm]

Honestly, every time I get such a notification, I somewhat feel the need to respond to it (my "chosen role" being somewhat into the direction of "project/community management").
Maybe just hiding comments as spam (instead of responding and thus making the important content go further up) is a practical solution?

Perhaps my current saved response also needs work in terms of openness/friendliness

Please refrain from posting +1 / requests for updates things on issues, as this makes issue-management harder.
Issues are for discussing what needs to be done how by whom.
We use 👍🏻 on issues to prioritise work, as always: Pull Requests welcome.

[ccoenen]

I would be totally fine with locking this issue.

I don't expect anyone to contribute meaningful insights to this. I think everyone involved is aware. The constant "oh, but I have an important need for this, surely this tips the scale" is really useless for everyone involved.

[bb]

I was happy to see this locked. Thanks @CommanderStorm. Here's a more complete list of good reasons: https://github.com/bradfitz/issue-tracker-behaviors

[M1CK431]

However contributors might want to post comments to provide progress update, right?

[douglasparker]

Yep, I'm also in favor of locking this issue.

I subscribe to notifications for issues that I am interested in that way I can follow development or discussion around development, but most of the time all I get is my email flooded with noise.

We all know this is a highly requested feature. I want it too. But all the extra noise just makes me want to unsubscribe.

You have to realize that a lot of us follow a LOT of projects and a lot of issues. When all of replies are bumps and +1's it gets annoying really quick.

[WoodyWoodsta]

Personal rule of thumb:

• issue has little to no engagement: add your context and any helpful info, by any means
• issue has >10 reactions or >10 comments: spare everyone the unhelpful notification

[DarrenRainey]

Recommend locking the thread so we don't get constant pings asking for updates.
One work around in the meantime would be to set uptime-kuma to listen on localhost and use some kind of proxy (perhaps nginx) to handle authentication either via LDAP or SSO.

[dawidsoftiq]

I've managed to deploy Uptime Kuma behind Authentik Proxy which provides easy way to authenticate users via multiple methods.

[WoodyWoodsta]

We have uptime behind https://www.ory.sh/oathkeeper/

[CommanderStorm]

Recommend locking the thread so we don't get constant pings asking for updates.

#128 (comment)