8000 Permissions Registry & Support for Vanilla's OP System · Issue #484 · feather-rs/feather · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
Permissions Registry & Support for Vanilla's OP System #484
Open
@ambeeeeee

Description

@ambeeeeee

Through discussion in previous months on the discord, I think(?) the idea of supporting Bukkit-style permissions natively. We must, of course, additionally support the Vanilla-style OP system since it is actually weirdly a part of the protocol. This issue outlines our steps forward in implementing this feature, considerations, and future steps to complete it.

Now

Our priority is to get something we can build on later, and this suits that need pretty well. The process of updating it shouldn't change much in existing usage of the permissions registry, which is a good sign that this path forward is the one to take.

The permissions system will involve two main parts:

  • The permissions registry which holds all information from the perms.json file after load-time (at the beginning of the server's execution or after some form of reload command). This is just a cache of the file on the disk already loaded into structures that will allow for easy querying.
  • The component that is attached to all Player entities that stores their permissions.

Additionally, something similar to these types will be used to store permissions:

pub struct VanillaPermissions {
    /// The OP level
    level: u8,
    /// Whether the player bypasses player count limits
    bypasses_player_limit: bool
}

Haven't figured out how to name this struct though

pub struct FooPermissions {
    /// A map of permission keys to values
    permissions: HashMap<String, String>
}

This is the struct that will be used as a component.

pub struct PlayerPermissions {
    vanilla_permissions: VanillaPermissions,
    foo_permissions: FooPermissions
}

There needs to be chaperone types to serde the permissions, but that's straightforward.

The registry type can be whatever works, probably something like a HashMap<Uuid, CombinedPermissionsStorage>.

It's important to maintain compat, so OP level should be saved to the ops.json file.

The op level should have a magic key minecraft.opLevel or similar that causes it to be written into the vanilla permissions instead of the bukkit-style system.

For now, permissions should be able to be queried, added, loaded on server load, saved on player leave (at a minimum)

Soon

The things described in this part of the issue are things we need to do soon, but aren't requirements (nor should they be added) for the first implementation of the system.

Higher priority:

  • Typed permission values
  • Quill support for permissions

Lower priority:

  • Commands to query permissions information
  • Utility trait to make querying permissions easier

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0