search

louislam / uptime-kuma

A fancy self-hosted monitoring tool
https://uptime.kuma.pet
MIT License
52.45k stars 4.72k forks source link

Allow basic User management without permissions #128

Open Nicklas2751 opened 2 years ago

Nicklas2751 commented 2 years ago

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 commented 2 years ago

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

Overall, great project!

jtagcat commented 2 years ago

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

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

Cristy94 commented 2 years ago

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

deefdragon commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

louislam commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.

acki commented 2 years ago

+1 We need this @louislam

foliovision commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.

Cloud-Kid commented 2 years ago

This feature is a must ! Multi-user support with different rights : Admin (That can add and modify settings or monitoring) and Viewer (That can only see the monitoring of certains website on a per name/tag basis) and more ...

Hope this will be available in the feature :) This can also extend to active-directory authentication !

iamdempa commented 2 years ago

I would like to have this implemented. Great work

mews-se commented 1 year ago

Oh yes. This is THE feature that needs to be implemented. Pretty sad to have to have several containers running the same application for different users ;(

adiastra commented 1 year ago

I would also really like to see this feature even in its most basic form. Seems a second admin user would be easy to set-up. Logins would need to reference user IDs, some user management forms would need to be added. That's all that is needed to start. After that we could reference a permissions table or even handle permissions as a simple delimited string in a column. I am not sure of the current structure but most of the functionality should already be there.

Terminal-Access commented 1 year ago

ALso Requesting multi-user support with an internal admin page allowing for permission and access control per user.

UltimateByte commented 1 year ago

Hello,

Having the possibility to create multiple admins and/or users with "view only" permissions would be essential for any team willing to use this otherwise nice tool.

All the best

apuleston commented 1 year ago

I understand that multi-user is a big ask, but this would really take the project to the next level. If there's a way to assist with this then I'd be very happy to.

ratmont commented 1 year ago

It would be great!!!

kirtan403 commented 1 year ago

Uptimerobot has also recently announced sub-users management

belyaev-ban commented 1 year ago

Need this. At least ability to add other users.

bravoman commented 1 year ago

Would be nice!

jjanderson commented 1 year ago

For my use case, I would be happy to charge sub-users a fee as they are mostly clients in any case. The project is more than welcome to this fee should it help drive development of this feature?

cocoonkid commented 1 year ago

Oh yes this would be so cool!

JakeyPrime commented 1 year ago

+1 to this, Atlassians recent outages and tech issues we're looking to fully move away.

ccoenen commented 1 year ago

Hi there.

If you came here to post "yes, this would be awesome", please stop right there.

This ticket does not need more "Duuude I would love it" messages. I am pretty sure the developers know that all of you would love this.

Can you please use the :+1: button like any sane person? I don't need to get notified about this whenever someone posts here.

I do need to get notified when this is implemented or otherwise changed in some meaningful way. Please keep this frequency clear.

UltimateByte commented 1 year ago

You're right @ccoenen I do believe at this point, the relevance for the feature is fully acknowledged.

Even though I don't speak JS yet, I'll try to at least bring some food to the table, by giving ideas for the specs of the feature. I hope it gives a starting point to JS devs out there. That's the most I can currently provide with my current free time and knowledge.

I just had a look at auth.js https://github.com/louislam/uptime-kuma/blob/master/server/auth.js It appears to me that it will seek through multiple usernames already and check if they are active.

    let user = await R.findOne("user", " username = ? AND active = 1 ", [
        username,
    ]);

Which means adding multiple admin users would be a matter of creating the menu allowing to add them to the database.

However, since if everyone is admin, it will cause issues, this feature requires some kind of user and privilege management. Also, if you're able to add users, you will want to be able to remove them as well. And once again, not everyone should be able to remove users or it will cause issues.

If you want to start simple for this feature, view and edit permissions would likely enough to close this issue. One admin user that can edit, and as many view users as needed.

If you want a more complex but more versatile system, then a "group" and permission system is likely the key. For that, you can add a "group" field to users in the database. There would then be "admin/viewer" group logic, possibly also a "superadmin" group that would be the only one allowed to create and remove users. Depending on the group, you can then define permission variables like "user_edit" ; "edit" (monitored entries) ; "view". Ultimately, when displaying features into the interface, these features would be shown depending on defined permissions. Superadmin users might only be created from another superadmin user or from the CLI.

Security concern though, depending on how it's implemented, users could make config writes with "POST" requests even though buttons or menus are not shown. So writing changes must also depend on the group or permissions, that way users cannot just send arbitrary "POST" requests for changing settings while they shouldn't have permissions to do so. A simple way to do that might be by adding conditional tests before making writes to the database. That can be a breaking feature so must be developed with care taking as many scenarios as necessary.

All the best.

stefanux commented 1 year ago

ACLs levels could be

access to monitors could have group or by tags (which seems to be more flexible because you dont need nesting groups).

DarrenRainey commented 1 year ago

+1 for this feature I'm considering deploying it for a few people but would like to set up a second admin account.

Coo-ops commented 1 year ago

OIDC would go hand in hand with multi-user support too. Thank you.

srsquare commented 1 year ago

+1 for this feature, even a simple auth system with basic acl's would be a great start! I dont really have time at moment to help with development, but I would be happy to offer project management and beta testing, etc. if anything like that would be helpful.

Chriss7788 commented 1 year ago

A very simple user management with three basic roles

would be perfect for the beginning.

DarrenRainey commented 1 year ago

I don't think a read-only group would really be required since everyone should be able to see the status pages.

Developer I would probably rename to maintainer or manager since most people may be mointoring services or programs that they don't have direct control over e.g. In my case I'm using it to monitor some internal tools at work so I can pass the alerts to the relevant teams to take care of.

One more thing I would add is that if active directory or ldap authentication is added it would be nice to be add to bind roles to group names so they're no need to manually configure each user.

almereyda commented 1 year ago

Maintainer is a good wording for a role between the public and the administrators.

Indeed a read-only user could be interesting, esp. for dashboards of internal tools. But that monitor could also run in a private, internal instance, instead.

But we are seeing that user management might also come with an additional requirement: Implementation of RBAC / ACLs for Uptime Kuma components.

mjh2901 commented 1 year ago

The simplest support would be adding a setting to the status pages "do not require authentication" Then we can build public and non public status pages.

CommanderStorm commented 11 months ago

Hello together, (sorry for pinging all the people who are subscribed)

@M1CK431 has stabilised this PR: https://github.com/louislam/uptime-kuma/pull/3571 Massive props as this has been a considerable effort.

Said PR does provide:

It does not include (due to size ⇒ keeping this PR reviewable):

=> the issues which are not covered in the PR should be managed in follow-up PRs

If you'd like to help to get this PR merged, you can help with:

FuckingToasters commented 9 months ago

can users regiter their own account with thier own site uptime checking?

M1CK431 commented 9 months ago

can users regiter their own account with thier own site uptime checking?

The first admin user create others accounts. Others accounts can change everything they want.

jc-odot commented 7 months ago

OIDC would go hand in hand with multi-user support too. Thank you.

Agreed, OIDC would be ideal for implementing in enterprise environments!

lbhopper commented 7 months ago

any testing branches for this feature?

CommanderStorm commented 7 months ago

See above:

M1CK431 has stabilised this PR: https://github.com/louislam/uptime-kuma/pull/3571

lbhopper commented 7 months ago

thank you!

On Tue, Nov 21, 2023, 3:06 AM Frank Elsinga @.***> wrote:

See above:

M1CK431 has stabilised this PR: #3571 https://github.com/louislam/uptime-kuma/pull/3571

— Reply to this email directly, view it on GitHub https://github.com/louislam/uptime-kuma/issues/128#issuecomment-1820587972, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3XE4DFRU5CVXYOV4O3J66LYFR4KPAVCNFSM5BIV2SIKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBSGA2TQNZZG4ZA . You are receiving this because you commented.Message ID: @.***>

Coo-ops commented 7 months ago

OIDC would be ideal for implementing in enterprise environments!

OIDC is already supported by Google, Apple, Github, Microsoft. Its not just for enterprise environments. But anyone who already has an account for something and doesn't want or need more. I run OIDC at home.

CommanderStorm commented 7 months ago

@Coo-ops This issue only targets the impelentation of multiple accounts. Please subscribe to https://github.com/louislam/uptime-kuma/issues/553 instead

GamerClassN7 commented 6 months ago

@louislam is there any ATA for multi user support , i think even [Dockge]() would benefit from that :)

CommanderStorm commented 6 months ago

@GamerClassN7

Like any self-respecting open source project run by volunteers we don't give out ETAs. It gets shippend once done. Please refer to #noestimates for a more in-depth discussion.

The PR #3571 is added to the v2.2-milestone. Please subscribe to this issue or the PR for progress.

hegerdes commented 5 months ago

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 commented 5 months ago

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.