Permission plugin intercompatibility and Custom Events

There is a mechanism with the current Bukkit API to handle custom events.

This allows plugins to send custom events that will be heard by all other plugins (that are listening for custom events).

If we were to define a custom event that checks permissions, then all plugins could use that event for checking permissions and it wouldn't matter what actual permission plugin the server is running.

For example, the special custom event could be defined as follows:

Code:

PermissionCheckEvent extends Event {

  Player player;
  String permission;

  boolean allow = false;
  boolean deny = false;

  PermissionCheckEvent(Player player, String permission) {
    super("PermissionCheckEvent");
    this.player = player;
    this.permission = permission;
  }

  void setAllow(boolean allow) {
    this.allow = allow;
  }

  void setDeny(boolean deny) {
    this.deny = deny;
  }

  boolean getAllow() {
    return allow;
  }

  boolean getDeny() {
    return deny;
  }

}

A plugin could call the event with something like:

Code:

boolean canUseCommand(Player player, String command) {
  Event e = new PermissionCheckEvent(player, command);
  getServer().getPluginManager().callEvent(e);
  return e.getAllow();
}

Any permission plugin could listen for custom events and update the event so that permissions are included.

Code:

public class pluginNameCustomListener implements CustomEventListener, Listener {
    public void onCustomEvent(Event event) {
      
        if( event.type != Type.CUSTOM_EVENT )  return;

        if( !event.name.equals("PermissionCheckEvent") ) return;
  
        <code to check permissions>

        event.setDeny(<result>);
        event.setAllow(<result>);

    }
}

This could also be used for block protection plugins (though I think there is a can-place official event for that).

 

While I am not entirely sure I like the way you structured your code, I agree with your idea, and support this proposition!

 

Anything in particular that you object to? Also, it sounds like there will be an official permissions system soon, so this might not be required.

 

It would be far better if the official permissions system was merely a well-defined interface (maybe with a default group/user-based reference implementation), possibly along these lines, as then individual server administrators would be able to choose whatever permissions back-end they wanted to use. I know I'd personally rather use a rule tables implementation than a group/user system.

One thing to note with your suggested code: Using a simple String scalar for encapsulating information about what a player is attempting to do won't really be sufficient for complex enough actions/plugins - and while you could technically pack arbitrary information into a String, that is a /horrible/ way of doing it; it'd be better to wrap it in a well-defined class.

 

custom events is interesting, I am wondering if this is better than the current method I have been advocating for inter-plugin communication?

My first question is what happens when you have nothing implementing that custom event? (no other plugins installed that are suppose to handle such a thing?)

 

Nothing.

MM has been using custom events from day one. I already have 5 custom events for minecarts. They work great.

 

Well if this is going to be some kind of standard between plugins then I recommend putting in a boolean Handled variable. So if something handled the request, it gets set to true, and you know if at least one thing took care of your event. (only works if everyone agrees to implement it obviously)

 

I agree.

 

Wow, this is absolutely my opinion on this, Shados. I made a tired rant (sorry) here: http://bugs.bukkit.org/issues/251#change-721

We really should put our command permissions concerns here, though: http://bugs.bukkit.org/issues/6

-Mattie

 

Well, I talked to Dinnerbone (who is implementing the current permissions plans) on Github and IRC a bit. Basically, he shares many of the concerns, but wants us to keep in mind that this is just the initial system; once a good plugin dependency resolution system is in place, a more final permissions system is likely to be developed (possibly with the currently indev one as the default backend). Or, at least, that's the impression I got.

Anyway, if you want to talk about it more, I'm usually on AIM/MSN/XMPP/TS3, details @ my profile.

 

Side note: Rather than just a Handled boolean, a HandlerHistory stack may be more appropriate, where the mod(s) operating on the event would each push on some information (i.e., an EventTrace object) about themselves (TBD). This would give a better trace, should one be needed. The Handled boolean is then just a check to see if the stack is empty.