[PluginSDK]Please add a parameter for the sender in onPluginCommandEvent

[Thomas]

In the callback onPluginCommandEvent there isn't a parameter containing the sender's client id.
Would be very helpfull, to identify "good" clients and ignore "bad" clients.

Somethink like:

void ts3plugin_onPluginCommandEvent(uint64 serverConnectionHandlerID, const char* pluginName, const char* pluginCommand, anyID fromID);

[Screech]

I agree. And I think an additional option for Ignore plugin commands (similar to the ignore whisper option, use contact list, if not there use default allow/deny setting) would be good.

[Thomas]

an additional option for Ignore plugin commands

What is that supposed to be good for?

If a plugincommand is not handled by a plugin, it is totally ignored. You won't see them in your client.

What if some user activates this kind of option, but has a plugin which communicates with pluginCommands?

[Screech]

What is that supposed to be good for?

If a plugincommand is not handled by a plugin, it is totally ignored. You won't see them in your client.

What if some user activates this kind of option, but has a plugin which communicates with pluginCommands?

He can restrict that the plugin will only communicate with "trusted" friends and ignore anyone else that may be running it.

Take the updated App Scanner for example. Maybe I want those on my friends list to see the apps and no one else.

[Thomas]

The current declaration of onPluginCommandEvent is this:

void ts3plugin_onPluginCommandEvent(uint64 schid, const char* pluginName, const char* pluginCommand);

In my opinion, this has multiple issues.

1) There is no "sender" parameter. So if client A sends some pluginCommand to client B, client A has to send his id (or some other signature) in every command to let client B know who sent the command.
Especially for open protocols this can lead to huge security issues if you don't use further security handling (end-to-end-encryption, certificate using, ...) in your plugin. If you know, how the message is "signed", you can easily fake commands. I guess the TS3 client has this sender information already but does not forward it to the plugin? Then this should be an easy fix only on the client side.

2) If I remember right, plugins can only receive plugincommands from the same plugin (on the remote site). So if two clients have the same plugin installed (same pluginname), the two plugins can communicate per sendPluginCommand/onPluginCommandEvent. So the parameter pluginName is somehow obsolete.

So all in all my request is to cut out the pluginName paremeter (if my assumption from 2) is correct) and add a sender/invoker parameter to the function decl.

[Thomas]

Thanks for merging, in fact I didn't remember, that I already requested this.

Any feedback would be nice. If you plan to fix this, I can stop getting headaches about some crappy workaround.

[Bluscream]

If anyone else might want something similar, check out Thomas implementation in pyTSon:

https://github.com/pathmann/pyTSon/b.../_plugincmd.py