uptime-kuma
uptime-kuma copied to clipboard
louislam
Feature: Multiple Users
⚠️⚠️⚠️ Since we do not accept all types of pull requests and do not want to waste your time. Please be sure that you have read pull request rules: https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma
Tick the checkbox if you understand [x]:
- [x] I have read and understand the pull request rules.
Description
This feature, would add the ability to have the main user, (admin user) to add other users, and the main user has the ability to give these users permissions, so they can only view the monitors, status pages etc. Or they can have management permissions, such as add, remove, edit
Fixes #128
Type of change
Please delete any options that are not relevant.
- New feature (non-breaking change which adds functionality)
- This change requires a documentation update (it could, but it really depends, will leave this here though)
( Just up for discussion and the okay from the project owner (@louislam) before I make any code, as the PR Rules go so none of these apply atm
Checklist
- [ ] My code follows the style guidelines of this project
- [ ] I ran ESLint and other linters for modified files
- [ ] I have performed a self-review of my own code and tested it
- [ ] I have commented my code, particularly in hard-to-understand areas (including JSDoc for methods)
- [ ] My changes generate no new warnings
- [ ] My code needed automated testing. I have added them (this is optional task)
Screenshots (if any)
Please do not use any external image service. Instead, just paste in or drag and drop the image here, and it will be uploaded automatically.
This feature I agree that will put Uptime Kuma into another level.
However, my answer is simply no. I don't recommend anyone working on it in this stage because it is a super super big task.
- Server + Frontend more than 150+ files have to modify in order to handle different permissions I believe.
- Add new components for managing users, permissions and user roles.
- A lot of discussions on how to define permissions. (e.g. If User A created a monitor, should it be visible to Admin? If Admin created a monitor, should it be visible to User A?)
- Security, there are a lot of API key such as notifications inside Uptime Kuma. Read-only user should not see it?
- Testing and reviewing all changes are always hardest part.
Didn't mention there are still so many pull requests I haven't reviewed yet. I think I will put my time on them first.
Well, I will say I begun this as a test to see it was even possible, I created ways to add sub users, remove them and let them login, now I haven’t looked at permissions but the way I was going to add them, a proper way, would use way less than 150 files, but If you still want a pause on this I can close it, and when you mention the notifications my idea of read only user is that they will get notifications, and can see everything but not able to remove users, add monitors etc.
@ItIzJR Would it be possible for you to share what you have done so far? It might help in making a decision if we can see how you are planning to implement this.
You could probably just commit it (you can always revert the commit later), or you could copy in some examples.
And you just want what I have done? Which is adding / deleting sub users and logging them in?
Yeah, just something so that we can see in code how you are thinking about implementing multiple users.
It didn't import correctly for some reason, so until I get back on tomorrow it'll have to be this way, if you check the repo for this under the "main" branch, the files will be in the areas with the commit message "sub user files"
and... I just realized I forgot to include the most important part when I committed them, which was the login stuff, hopefully this will get you the main idea of how I will be planning on implementing these files though, also if you want I can also come up with the best way of implementing permissions, with as few changes as possible, while being secure as possible, I have actually done this before so I don't think it will be too hard.
I just realized I forgot to include the most important part when I committed them
I see nothing changed in File changed tab.
That would be due to the weird way GitHub imported it, whenever I get back from work if I have time I’ll fix it, but like I said the changes are in the files with “sub user files” in the main branch if you want to manually look at them, Ik it takes a lot more time, or you can wait till I get it to be fixed.
Alright I have added all the files into main and they show up under the changes, also it seems after merging whatever you pulled today it throws and error, in your commit checking.
This is what the files produce:
https://user-images.githubusercontent.com/76182714/210155403-e0ccbff1-4d20-4d1a-ae29-1078daaf3a25.mp4
https://user-images.githubusercontent.com/76182714/210155405-43a835f2-d5c5-47e8-88b1-d63be5865228.mp4
I see the problem here. The reason we cannot see the commits is because they have been made on the main branch of your repo but this PR is for the master branch of your repo. If you just change the branch this PR comes from we will be able to see the changes
Oh I didn’t notice that I’ll update it real quick, then I have to go but that gives you guys time to take a look
just my 2cents. If you build something like this you need to plan for support of different authentication methods in mind for example LDAP/AD etc
just my 2cents. If you build something like this you need to plan for support of different authentication methods in mind for example LDAP/AD etc
Yes, definitely, the support (or at least designing/planning to support) of external authentication systems is a must, especially if we want to future proof.
~~Hi, because Uptime can only create one user, there is one case: if we can't contact the admin (especially 2FA is enabled), then it seems there is no way to log in to Uptime. Maybe provide a way to account recovery?~~
Just noticed this issue: https://github.com/louislam/uptime-kuma/issues/2238 :) It's helpful!
Sorry for my delay, I’ll get the code situated asap, been a busy week at work. I would definitely be able to implement that, thanks for the suggestion, and that is if they end up approving this.
@louislam In terms of a permissions system, could we do something a bit like OAuth scopes? E.g: monitor:read, monitor:write and so on. For another example of these, you can have a look at the GitHub personal access tokens. This would allow us to just have all the scopes for a user in the database (schema to be determined) and then each page simply checks to see if the user has the required scope for that specific page. This would also probably make it fairly simple to implement the permissions levels for OAuth in future if that is desired. This would put the requirement to validate permissions on the individual pages instead some centralised place, making it more scalable (in my opinion). This would also allow admins fine grained control over user permissions. I would be interested to hear what you, and others think.
P.s. Should we use some sort of discussion system where people can discuss the big changes that don't quite fit into issues (like user permissions). Perhaps enabling GitHub discussions could be an option?
Why not just start without permission system and make all users admin at first?
- Uptime kuma is light-weight enough to use multiple instance for different stuffs, and the minimal support for multi-user is enough for most(maybe up to 80%) cases.
- This would be easier to impl, with less effort and less effect of current codebase(maybe less than 20% compared to with permssion system).
- This would have less UI/UX or design work, make it much acceptable by louislam
Gonna be honest forgot this was open, Louis didn’t seem to be a fan of having someone make this so I privately made it myself so that I could use the feature I wanted, if anyone else were to want this I could help them with implementing it, but it has multiple user and permission system already.
Why not just start without permission system and make all users admin at first?
- Uptime kuma is light-weight enough to use multiple instance for different stuffs, and the minimal support for multi-user is enough for most(maybe up to 80%) cases.
- This would be easier to impl, with less effort and less effect of current codebase(maybe less than 20% compared to with permssion system).
- This would have less UI/UX or design work, make it much acceptable by louislam
Just make my thought clear: we need to push things forward, and build from small part maybe useful enough, also acceptable by louislam with less UI/UX and design stuff. What I really want is introduce this awsome feature into Uptime Kuma, in a way louislam would like it. Sorry to bother you, but let me ping @louislam cause I want to know your opinion.
Just make my thought clear: we need to push things forward, and build from small part maybe useful enough, also acceptable by louislam with less UI/UX and design stuff. What I really want is introduce this awsome feature into Uptime Kuma, in a way louislam would like it. Sorry to bother you, but let me ping @louislam cause I want to know your opinion.
Yeah I gotcha, I’ve got a working version and the only UI added is a sub user management system and permission system, all we would need is Louis’s approval and then I could move the private repo into the one for this pr.
How do i install ItIzJR's multi user uptime-kuma it just says:
error: pathspec '1.19.2' did not match any file(s) known to git
@ItIzJR Could you close this PR? https://github.com/louislam/uptime-kuma/pull/3571 implements the same feature, but is more mature ⇒ has a chance of getting merged ^^
