Hmm. An interesting point here. If you want to make a plugin secure, then wouldn't you also need to have some way to tell the client, "I refuse to close!", not to mention something like, "OnPluginEdit", and even "OnPluginReload", which could return a "true" if you want to allow those events, or "false" if you don't want someone to do them?
I mean, those don't prevent someone from "manually" editing the plugin externally, or the world file or client default settings to "remove" the plugin or change its behavior, but you wouldn't be able to simply delete the plugin from the world, the default plugins *or* edit it using notepad, then reload it. As long as there exist ways to remove or reload a plugin, you haven't prevented anything by having callbacks to help you prevent them from simply disabling it. And I can imagine cases where someone might, as part of something specific to a mud, even want to use basic encryption on a plugin (or the code at least), then have as part of that code methods that prevented anyone from *hacking* it to change the behavior. In other words, if you can't remove/disable, etc. a plugin *without* permission, like a password, you could make more or less secure plugins.
Mind you.. It might be necessary to include an encrypted password in the plugin itself, and have it "auto-call" a text entry box to input and check against it, *if* you allow it. So, instead of simply refusing to unload, reload, etc., the behavior would be like:
if return == true {call allow} else {
call password request
if request_return == false {
call warn_failure
else
call allow
};
In other words, let people provide some "minimal" protection to a plugin, including something like the client lock, where disabling/enabling is done "only" through the stored password for that plugin.
Not perfect, since they could still decrypt the password hash, and some languages probable don't support *any* encryption of the script data (might require adding an encrypt/decrypt to the plugin load code to do it right). However, since its the working part that would be encrypted in such cases, and the password is done "through" callbacks to that working code, changes to aliases, etc. would do nothing at all, other than screw up the encrypted plugin.
Mind you, I can think of a way around that, like adding your "own" non-encrypted code block, then redirecting an alias to call that code instead, but that only works if there is no code dependencies and you know enough about how the "existing" code works to fudge changes into the plugin.
---
Anyway, point is, even with those callbacks suggested by Cage_fire_2000, there are still very simple ways to disable/change/remove the plugin causing you a problem, if you are someone trying to bypass the lock.
Oh, and to be clear, if you wanted to create such a means to secure the plugin, then you need an "OnPluginUnload", *as well as* an "OnPluginClose". Why? Because for something like ActiveX objects, close needs to release them, if you want to do things cleanly, as well as perform other functions. This means the logic needs to be:
1. OnPluginUnload - To determine **if** the plugin will let itself be unloaded in the first place.
2. OnPluginClose - To perform the tasks needed to close things down, assuming the Unload allowed it.
And of course, there needs to be logic in the client, so that closing the world itself, or the client, "won't" trigger "unload" function, or alternatively, the client needs to ignore a "do not unload me" value, if the client/world is closing and it "must" unload. Obviously, if you don't have them seperate, there is no way to deny the event without messing things up, and no separation between code you may "need" to have execute *only* if you do remove/reload it, from that which just determines "if" it should allow those things. You don't want to kill and ActiveX component, for example, if the very next act is to tell the client, "Oops! Don't unload me, I am still doing things." Its not re-executing OnPluginInstall in that case, so your ActiveX, or anything else that relies on staying loaded, until the plugin is unloaded entirely, would be lost, even though it is still needed. |
![[Next page]](/images/thin_next.gif){kind=small}
![[Go to top]](/images/gototop.gif){kind=small}
top