No longer can Disable Edit Mode after recent auth additions

voc0der commented 8 months ago

Environment

Docker

Version

latest

Describe the problem

Used to be that you - EDIT_MODE_PASSWORD= in docker or env variable and you could lock the homarr grid via the menu dropdown in the top right.

Sure you can log out or as someone else, but then it disables other things, like pihole controls, or things I haven't thought about.

Logs

No logs needed.

Context

No context needed.

Please tick the boxes

[X] I confirm that I attached the proper logs
[X] I've read the docs
[X] I've checked for duplicate issues
[X] I've tried to debug myself

manuel-rw commented 8 months ago

This is intended behavior and noted in our breaking changes: https://homarr.dev/blog/2023/11/10/authentication#breaking-changes

We will add a more granular permission system in future versions. The environment variable you mentioned was always marked as experimental and was prone to removal for a long time. As an alternative, you can use https://homarr.dev/docs/customizations/board-customization#access.

voc0der commented 8 months ago

Sorry, my bad, I should've read that. Still, I guess this issue was worth creating based on your response.

Unfortunately creating or using anon users does not help because of the issue stated above. Looking forward to any changes that go towards re-enabling this functionality!

Happy to see the project move forward at any rate.

SeDemal commented 8 months ago

Could you develop on why that functionality needs to be reinstated? The very reason it was present was for security and preventing non authorized user to modify the board. As that security is now behind admin users, the need for it disappeared. Even as an admin you don't need to constantly be in edit mode, you can use the board normally as is.

voc0der commented 8 months ago

For example, if you add a widget like the pihole one, and then go anonymously to the board, you cannot use Enable all Disable all . That panel is not drawn for anon.

Curiously, you can still disable and enable them by clicking on the children for each pihole instance which do not get hidden. That appears to be a separate bug.

In either case, for many homelab users, that is one such use case where being logged in helps, but it used to not matter. But now being forced to log in means I can edit my screen.

Ultimately, I want to prevent myself from modifying the page but having the same experience, which was what I used that feature for, not security. Ironically, I also would benefit from https://github.com/ajnart/homarr/issues/1345 this, but so would others.

Just think about it it from a perspective of a user who often misclicks stuff. Most peoples boards are full of buttons. At least the crap on the board is meant to be clicked. Given that people misclick shit all the time, some people want to be able to make more of their board static so that it doesn't matter if they misclick. Phones suck. People often also misclick things on their phone they never meant to.

SeDemal commented 8 months ago

In either case, for many homelab users, that is one such use case where being logged in helps, but it used to not matter. But now being forced to log in means I can edit my screen.

You can make non admin users that can't edit the board.

The pihole not being able to be toggled by non admins is intentional, as a non admin shouldn't be able to change the way a whole network traffic behaves. Following your logic, we wouldn't want a miss-click to disable pihole.

It still being able to be disabled through the badge is indeed the inconsistency that needs to be fixed though.

For the issue you mentioned, I commented a custom CSS there to tackle that issue. We can't implement every little thing like that one as options, especially if it can be solved in CSS like that.

As of now, the only things that are not available out of an admin account are:

toggling dns hole
Approving overseerr requests
Editing the notebook (this one issue resides deeper though, as the system is right now we couldn't even if we wanted)
Pausing the nzb clients

All those things or almost are definitely things you don't want to be clicking on accident and them being available only to admins makes the most sense.

My suggestion, make normal users for your boards, they won't be able to modify like you want to. Make an admin account that you would only log on fully knowing you need to be careful to perform duties that require admin access, which is not a lot of it.

voc0der commented 8 months ago

I appreciate the thorough response and explanation and css.

Suppose I could also just write css to disable the edit button as well!

manuel-rw commented 8 months ago

I agree with @Tagaishi. The authentication update was meant to replace some of the parts that OP mentioned. We already secure the widgets and apps behind the edit mode which makes accidents editing a rare occurrence. I think this is mostly an edge case. As Tag mentioned, if you have dangerous controls or widgets, then you should reconsider who has access, how you organise your dashboards or disable them via CSS. However it should be noted that CSS is not viable at all to improve security - it runs on the client and can therefore be easily manipulated. We are currently working on a more detailed permission system. We still don't have the specifics decided but it will most likely offer a permission to interact with widgets - so you could just turn that off for the users.

Do you need any further assistance or information? If no, can we close this issue as is? We will be tracking the permissions in a different ticket.

ajnart / homarr