You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 26, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 26, 2024. It is now read-only.
Module API for validating user / room deletions by the admin API #12026
In some cases, we want to prevent administrators from deleting certain rooms from the homeserver where they are critical to the functionality of a service (e.g. monitor bots / monitoring rooms). A simple API that takes a room_id/user_id parameter and returns a boolean value depending on whether the room/user should be deleted would be ideal.
It kind of sounds to me like this would better be implemented with e.g. a proxy in front of the admin API? Using modules to prevent admin API actions feels a bit wrong to me.
It feels a bit fragile to put a proxy in front of some requests to prevent something, given there are usually multiple ways to invoke actions. It might not even be possible to fully prevent it.
Using modules to prevent admin API actions feels a bit wrong to me.
This is more of a protection measure to avoid accidentally causing an accident (think visudo) more than total preventation. An admin can easily disable a module if they are really intent on killing off a room or user. This is just to prevent deleting resources that shouldn't really be removed.
I suppose an alternative to this would be a protected users/rooms list in the config where you have to pass an additional flag if you are really sure you want to delete something, but it feels a bit clunky.
Activity
babolivier commentedon Feb 18, 2022
It kind of sounds to me like this would better be implemented with e.g. a proxy in front of the admin API? Using modules to prevent admin API actions feels a bit wrong to me.
Half-Shot commentedon Feb 18, 2022
It feels a bit fragile to put a proxy in front of some requests to prevent something, given there are usually multiple ways to invoke actions. It might not even be possible to fully prevent it.
This is more of a protection measure to avoid accidentally causing an accident (think visudo) more than total preventation. An admin can easily disable a module if they are really intent on killing off a room or user. This is just to prevent deleting resources that shouldn't really be removed.
I suppose an alternative to this would be a protected users/rooms list in the config where you have to pass an additional flag if you are really sure you want to delete something, but it feels a bit clunky.
Half-Shot commentedon Mar 10, 2022
Done in #12028