Gammon Forum : MUSHclient : Suggestions : Enable/disable plugins through the plugin menu

Register forum user name Search FAQ

Gammon Forum

Entire forum

MUSHclient

Suggestions

Enable/disable plugins through the plugin menu

Enable/disable plugins through the plugin menu

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2

Posted by

Shaun Biggs USA (644 posts)

Date

Sat 02 Jun 2007 07:21 AM (UTC)

Message

We have EnablePlugin function, but no quick interface on the plugin menu (ctl-shift-P). Could a button or two be added to toggle a plugin enabled or disabled? And perhaps a little flag on the far right part of the list showing if the plugin is enabled too. Sometimes I'd just like to pop open the list and turn off one of my plugins for a bit.

It is much easier to fight for one's ideals than to live up to them.

Posted by

Cage_fire_2000 USA (119 posts)

Date

Reply #1 on Tue 05 Jun 2007 12:09 AM (UTC)

Message

If you're going to do that, you may or may not want to add OnPluginEnable and OnPluginDisable callbacks, I'm not sure if OnPluginInstall and OnPluginClose handle those events. To stop external programs or something, or in the case of my ClientLock plugin, to disconnect the world if somebody tries to circumvent the lock by disabling the plugin.

Posted by Shadowfyr USA (1,786 posts) bio

Date Reply #2 on Tue 05 Jun 2007 01:18 AM (UTC)

Message

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.

Posted by

Shaun Biggs USA (644 posts)

Date

Reply #3 on Tue 05 Jun 2007 03:16 AM (UTC)

Amended on Tue 05 Jun 2007 03:24 AM (UTC) by Shaun Biggs

Message

erm... that last post got a bit odd very quickly... Not allowing a plugin to be "unloaded" borders on the insane... of course a plugin should be able to be unloaded no matter what. The OnPluginDisable function would be a great idea to add for things like the client lock plugins, but I'd hate to have to explain to people why they can't just remove a plugin that they decide they don't want anymore.

If you really want to get picky about disabling plugins, just have a no_disable option (defaulting to "n") for the plugins which would stop the EnablePlugin function from working, and you would have to uninstall the plugin, tripping the OnPluginClose function. That solves all those problems with just a simple if statement or two instead of mucking about with encryption or limiting people's removal of a plugin.

It is much easier to fight for one's ideals than to live up to them.

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #4 on Tue 05 Jun 2007 06:16 PM (UTC)

Amended on Tue 05 Jun 2007 06:17 PM (UTC) by Shadowfyr

Message

Well, my point is that to unload/remove it, you would need to use the *same* password as you use to unlock it. In other words, its truly *secure* from tampering. It shouldn't be impossible to remove it, just not easy, if you get my meaning. As it is, with something like a client lock, preventing it from being "disabled" is useless, if you can't safeguard against them simply deleting it entirely.

Posted by

Tsunami USA (204 posts)

Date

Reply #5 on Tue 05 Jun 2007 06:41 PM (UTC)

Message

I can't see why you think plugins need to be secure at all, or even should be, given that they are insecure and untrusted by their very nature. Users should be able to remove/uninstall/disable a plugin at any time no matter what its doing.

Posted by

David Haley USA (3,881 posts)

Date

Reply #6 on Tue 05 Jun 2007 09:23 PM (UTC)

Message

I'm not sure why I would want to install a plugin that would have password protections against removing it...?

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #7 on Tue 05 Jun 2007 10:53 PM (UTC)

Message

Quote:

If you're going to do that, you may or may not want to add OnPluginEnable and OnPluginDisable callbacks ...

They already exist.

See:

http://www.gammon.com.au/scripts/doc.php?general=plugin_callbacks

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #8 on Tue 05 Jun 2007 11:00 PM (UTC)

Message

Quote:

If you want to make a plugin secure ...

I don't, to be honest. As you say, you can always edit the plugin externally, so I think this is unnecessary extra complication.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #9 on Tue 05 Jun 2007 11:00 PM (UTC)

Message

Quote:

Could a button or two be added to toggle a plugin enabled or disabled? And perhaps a little flag on the far right part of the list showing if the plugin is enabled too.

That is now implemented in version 4.08.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Shaun Biggs USA (644 posts)

Date

Reply #10 on Tue 05 Jun 2007 11:33 PM (UTC)

Message

Quote:
As it is, with something like a client lock, preventing it from being "disabled" is useless, if you can't safeguard against them simply deleting it entirely.

The post RIGHT before that:

Quote:
If you really want to get picky about disabling plugins, just have a no_disable option (defaulting to "n") for the plugins which would stop the EnablePlugin function from working, and you would have to uninstall the plugin, tripping the OnPluginClose function.

The SECOND post of the thread:

Quote:
If you're going to do that, you may or may not want to add OnPluginEnable and OnPluginDisable callbacks, I'm not sure if OnPluginInstall and OnPluginClose handle those events. To stop external programs or something, or in the case of my ClientLock plugin, to disconnect the world if somebody tries to circumvent the lock by disabling the plugin.

Now people can't mess with your character while you are gone. If you want everything to be really locked down, just pop open a utils.inputbox which will require a password to be entered before closing, which will disable and access to any plugin menus, but it will also halt a good deal of the program while the script is running, so you won't get any updates on the screen. The password could even be set per lock this way, so there is no chance of people grabbing it, even without encrypting the data... just wipe the variable afterwards.

It is much easier to fight for one's ideals than to live up to them.

Posted by

Cage_fire_2000 USA (119 posts)

Date

Reply #11 on Tue 05 Jun 2007 11:51 PM (UTC)

Amended on Tue 05 Jun 2007 11:56 PM (UTC) by Cage_fire_2000

Message

Wow, they already exist. I must've missed them when I was browsing the help file... I guess I'll have to add those to my ClientLock plugin... As for the whole stopping a plugin from unloading thing, I agree, it's insane. I can't think of any situations where you'd need to do that. In the case of my ClientLock plugin, disconnecting the world is secure enough as long as you don't save your username and password in the autoconnect screen. For any other purposes you could just say don't stop the plugin in the middle of such and such an action in the help file, that's what it's for.

My ClientLock plugin is secure enough I think. It stores the password in a local variable and not with SetVariable, so it can't be gotten with GetPluginVariable, it doesn't log the commands where the password is entered so it can't be found that way. I don't want it impossible for them to uninstall or disable my plugin, in case they forget their password, but if they do, I disconnect because only they should know the password to their character, if somebody else knows the password it defeats the purpose of the clientlock, because they could always connect from another computer or start another instance of MUSHclient or something. Encryption is silly since one of the good things about plugins is that other people can look to see how they're done and they can make their own.

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #12 on Wed 06 Jun 2007 07:29 AM (UTC)

Message

Quote:

If you really want to get picky about disabling plugins, just have a no_disable option (defaulting to "n") for the plugins which would stop the EnablePlugin function from working ...

A quick browse of the source shows that it should be possible to make an OnPluginDisable function, and in it, re-enable itself.

That way, the plugin can't be disabled. They can close it, yes. For that matter they can power the PC off.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Cage_fire_2000 USA (119 posts)

Date

Reply #13 on Thu 07 Jun 2007 12:37 AM (UTC)

Message

If you really want to encrypt it, there's the microsoft script encoder tool, I found it when I was browsing downloads.

I think this is it.
http://www.microsoft.com/downloads/details.aspx?FamilyID=e7877f67-c447-4873-b1b0-21f0626a6329&DisplayLang=en

I haven't tried it, but it sounds like what you want.

Posted by Shadowfyr USA (1,786 posts) bio

Date

Reply #14 on Thu 07 Jun 2007 12:59 AM (UTC)

Amended on Thu 07 Jun 2007 01:01 AM (UTC) by Shadowfyr

Message

Ah. But powering off the PC would also disconnect the world, as would closing the client, or forcing it to close, if it was locked up. But, as someone else mentioned, it may be possible to "freeze" the client, in a sense, by popping open a dialog in scripting.

Mind you, I don't think that is necessarily a good solution, since it would halt everything in the client, including display or processing of other text from the mud. And what happens if you are gone so long that the buffered input from there fills up the buffer available? You need something that can lock it *without* freezing the rest of the application, so you can leave it indefinitely, not for 2-3 minutes, while you hope too much text doesn't arrive from the other end. Having the script suspend things doesn't sound like that great of an idea imho. But that brings us back to the prior issue.

Now, if you want a *real* lock system, you also wanted to let the client still do "most" things, *but* you don't want secure plugins, then one solution would be to add something like:

world.requestpass(password_hash)

The plugin doesn't need to be secure, since all its doing is:

sub lock_me
  if mypass = "" then
    do
      temppass = messagebox("Lock code:")
    loop until temppass <> ""
    mypass = hash(temppass)
  end if
  requestpass("Unlock code:", mypass)
end sub

sub OnPluginPass(bool)
  if bool then
    exit sub
  else
    requestpass("Invalid Code!/n/nUnlock code:", mypass)
  end if
end sub

Note, this has sanity checks in it, to make sure that a password of *at least* one character is entered. It could be changed so that hitting enter would instead do "exit sub", thus bypassing the lock system. The reason for using a callback, instead of treating the password dialog, which would return a boolean directly is to "prevent" client locking in the script. Each call to the password request would exit the script *after* the dialog displays, thus the script and everything else can still work, even while input from the user is "locked" to the top level dialog.

Again, this doesn't require that the plugin be secured at all, but it **does** prevent the client from locking up for 2-3 hours you are AFK, when we really can't be sure what the client or the connection will do if the client isn't able to do anything at all, since the script, using a normal dialog, is going to be frozen. Which, as I said, is imho, a bad idea.

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

56,232 views.

This is page 1, subject is 2 pages long: 1 2

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Comments to: Gammon Software support
Forum RSS feed ( https://gammon.com.au/rss/forum.xml )