Skip to content
This repository was archived by the owner on Apr 26, 2024. It is now read-only.
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

Closed

Description

@Half-Shot

Description:

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.

Activity

  1. babolivier commented on Feb 18, 2022

    @babolivier
    Contributor

    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.

  2. Half-Shot commented on Feb 18, 2022

    @Half-Shot
    CollaboratorAuthor

    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.

  3. added
    T-EnhancementNew features, changes in functionality, improvements in performance, or user-facing enhancements.
    on Feb 23, 2022
  4. Half-Shot commented on Mar 10, 2022

    @Half-Shot
    CollaboratorAuthor

    Done in #12028

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    T-EnhancementNew features, changes in functionality, improvements in performance, or user-facing enhancements.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions