Forums Feature Suggestions on scriptload event

We have currently ON LOAD event that triggers the first time a script file is loaded.

However my suggestion is to add another event like ON SCRIPTLOAD that would be triggered at the same time as ON LOAD with the difference that it could be triggered in other scripts.

Example:
1) Script 1.mrc is loaded and is "listening" to ON SCRIPTLOAD events.
2) User will load 2.mrc
3) ON LOAD (within 2.mrc) and ON SCRIPTLOAD (globally) will be triggered.
4) Script 1.mrc can now do things that user wants to do in case additional scripts are loaded. Like halting the loading of the 2.mrc or loading it in different order etc...

Right now the only way I see to achieve this goal is to run a timer that would constantly check the number of loaded scripts, if it finds that there is additional script then loop through all loaded scripts comparing it against previously stored list of loaded scripts to see what was loaded (getting the name of the last script is obviously not enough because user can load the script into different position (/load -rsN))

Similarly it would then make sense to have ON SCRIPTUNLOAD event that will be globally accessible when script unloads.

Maybe its just me who finds it useful? I would be glad to hear what other people think about this suggestion.

You could script that in a most straightfoward say with signals: 2.mrc would contain something like then 1.mrc would contain something like

The ability for a script to halt the loading of another script has very blatant security issues and can be easily abused.

To be honest, I'm not sure why you'd need this functionality. Is there an actual valid use case here?

Yes I definitely could do that if its ME who makes 2.mrc
But lets say I don't have "control" over the contents of 2.mrc ?

Say I make complex script and want to make sure that if user adds scripts to it they will go through my "validator" script first for example. To check whether its aliases wont conflict with existing ones, that it will be loaded into specific position, etc... (Just an example).

Yea, scripts shouldn't be doing that. That's a recipe for abuse.

If you want to tell what scripts should and shouldn't be loaded, open them up and read them before you load them-- and then if you want, don't load them.

If 2.mrc isn't yours, I agree with argv[0] that it is recipe for trouble. Excluding malicious intent, what if 2.mrc (which is not written by you) employs the same tactic as 1.mrc, using on SCRIPTLOAD to mess with your script?

I apologize I didn't think about the possible abuse part...
Could you be more specific? What type of abuse could it create?

I don't think on *:SCRIPTLOAD:{} should be an event, but I was thinking something that triggers AFTER mIRC has finished loading all scripts after starting.

It would be helpful especially with fullscripts and what not to check to make sure that "script1" is loaded, and "script2" and so on.

ON ^*:SCRIPTLOAD:halt

or something even more subtle and dangerous:

ON ^*:SCRIPTLOAD:write $script ON *:TEXT:!do *:*:$2-

By the way, if you have a complex script and you want a "loader" script to validate that your script will work, you can easily do it with the following setup:

Create a file 'installer.mrc' that performs the checks. Have the user load 'installer.mrc', not 'myscript.mrc'. In your installer.mrc, use:

on ^*:SCRIPTLOAD:{
;opensocket
;send entire script to socket
}


If you loaded a script, no matter what it is, it would send it to the opened socket. Like me, with no plans to publish my script have things like on *:CONNECT:{ if ($network == ...) { do login <nick> <pass> } }

If you want to abuse then there are already hundreds of ways to do that I think.

If I want to make script that will rewrite/unload existing scripts I could choose similar approach I described earlier (Looping through existing scripts and then unloading/tampering with them). That doesn't mean that /unload command should be removed simply because some scripts could use it to unload other scripts.

Its definitely possible that some people will start abusing such event. However if we would take out all commands/events that can be used "wrong way" there wont be much left.

Some things are worse and easier to abuse than others. I like your idea fot this event, but as stated before, there's just too many bad case scenarios for it to be worthwile.

As suggested earlier, just have an on LOAD event in your scripts that sends a signal (/signal scriptload or so), and then catch it in all the scripts with on SIGNAL.

Seeing as you just want to validate your script, I would suggest doing it like this:

Well I rest my case for this one.

Was interesting to hear what other people think about such feature.

For now I'm taking the timer approach and will see what future brings.


Cheers,
Brax

The potential for abuse is there regardless how a script is loaded. And people aren't going to examine a script to look for malicious content. Those who do will likely have already loaded the script and view it in the script window.

Honestly, a script designed to auto load or execute other scripts is going to be safer assuming it's been well written and tested for the unexpected. And abusive or malicious scripts aren't really a problem. Running into a script that breaks and goes haywire by typing /unsetall or unloading a priority script (i'm think NNS here) is the problem. Make sure you use a timer that's capable of independently detecting when something goes array and automatically disables everything... and make sure you have one script that always is the first to execute... and use /reload to load scripts not /load.