uptime-kuma
uptime-kuma copied to clipboard
louislam
Allow basic User management without permissions
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.
In addition to that, an extension of this feature would be LDAP integration with group to permission mapping.
Overall, great project!
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.
This is a highly requested feature, are there any plans to implement it? Is it being considered?
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.
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.
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.
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 🤓
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.
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.
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
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.
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 !
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 ;(
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.
ALso Requesting multi-user support with an internal admin page allowing for permission and access control per user.
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
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.
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?
+1 to this, Atlassians recent outages and tech issues we're looking to fully move away.
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.
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.
ACLs levels could be
- admin (setup preferences and global notifications)
- developer (add/delete monitors but no global settings)
- user (readonly, just set up own notifications) für status pages there is a use-case für setting maintenance messages too.
access to monitors could have group or by tags (which seems to be more flexible because you dont need nesting groups).
