mIRC Home    About    Download    Register    News    Help

Print Thread
#174608 10/04/07 03:58 AM
Joined: Apr 2007
Posts: 4
B
Beau Offline OP
Self-satisified door
OP Offline
Self-satisified door
B
Joined: Apr 2007
Posts: 4
This script is designed to prevent naive users from altering the variables in your script's interface, be it by capricious injection of code into the Remotes', or command-lined method.

It prevents bad altering of variables that might disrupt your scripts' integrity and/or functionality, by injection the "-o" switch into the "/set" command.

"-o" is a short for "overwrite", if you do not include the switch, mIRC will search if a variable already exists asigned to what you wish to created, and will create a different variable if so.

So if Billy tries to create %variable and %variable already exists, it'll be %variable(2) instead.

If Billy tries to create %variable once again, since %variable and %variable(2) already exist, %variable(3) will be created.

Any other switches(-snzu#) will be applied to the new decoy variable, and your script's original variables will remain intact.

I hope you enjoy and that no glitches appear, I worked hard to make it clean and functional.

Here's a simple .gif animation illustrating how it works:

Link

Code:
alias set {

  ;Variable-Defender BETA
  ; by Beau/Crystalline (you can remove this credits if you wish to, but that would be mean. (: )


  if $left($eval($1,1),1) == - && *o* !iswm $1 {

    ; This is the "if" that detects the "-o", the "/set -o <%var> [value]" kind of input-
    ; will enforce an over-write of the variable even if it already exists.

    ; The injection of "-o" is(or seems to be as of this BETA version.) completely compatible with the other existing-
    ; switches already present in mIRC.

    if $left($eval($2,1),1) != % {
      echo $color(info text) -a * /set: invalid parameters. 
      halt  
    }
    if $var($eval($2,1)) != 0 {
      %loop.varcheck.debug.set.tmp = 2
      while $var($+($eval($2,1),$+($chr(40),%loop.varcheck.debug.set.tmp,$chr(41)))) != 0 {
        inc %loop.varcheck.debug.set.tmp
      }
      set $remove($eval($1,1),o) $+($eval($2,1),$+($chr(40),%loop.varcheck.debug.set.tmp,$chr(41))) $3-
      echo $color(info text) -a * /set: mIRC detected you attempted to overwrite an existing variable, to protect other scripts' integrity your request has been stored as ' $+ $+($eval($2,1),$+($chr(40),%loop.varcheck.debug.set.tmp,$chr(41))) $+ ' instead.
    } 
    else { set $1- }
  }



  elseif $left($eval($1,1),1) != - { 
    if $left($eval($1,1),1) != % {

      echo $color(info text) -a * /set: invalid parameters.
      halt
    }

    if $var($eval($1,1)) != 0 {

      %loop.varcheck.second.debug.set.tmp = 2

      while $var($+($eval($1,1),$+($chr(40),%loop.varcheck.second.debug.set.tmp,$chr(41)))) != 0 {
        inc %loop.varcheck.second.debug.set.tmp
      }
      set $+($eval($1,1),$+($chr(40),%loop.varcheck.second.debug.set.tmp,$chr(41))) $2-
      echo $color(info text) -a * /set: mIRC detected you attempted to overwrite an existing variable, to protect other scripts' integrity your request has been stored as ' $+ $+($eval($1,1),$+($chr(40),%loop.varcheck.second.debug.set.tmp,$chr(41))) $+ ' instead.
    } 
    else { set $1- } 
  }



  elseif $left($eval($1,1),1) == - && *o* iswm $1 { set $1- }

  unset %*.debug.set.tmp
  halt
}



v. 1.0 - basic.
v. 1.1 - removed uneccessary /echoes remaining from beta hours.

Last edited by Beau; 10/04/07 06:05 AM.
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
Ok, I didn't test this because I don't have time right now... but what happens when someone has a script that /sets a variable and your alias sets it as a different variable name and then the user's script tries to check it later? It would be checking the wrong variable. Also, what happens when a script sets a variable multiple times? Will this just keep making more and more copies of the variable rather than changing it?

As I said, I didn't test it, so maybe these problems are already addressed by the alias. However, if they aren't, then this alias is likely to cause more problems for the "naive" user who runs someone else's script that isn't designed to work hand-in-hand with your alias and just assumes that /set works the normal way.


Invision Support
#Invision on irc.irchighway.net
Joined: Apr 2007
Posts: 4
B
Beau Offline OP
Self-satisified door
OP Offline
Self-satisified door
B
Joined: Apr 2007
Posts: 4
Originally Posted By: Riamus2
Ok, I didn't test this because I don't have time right now... but what happens when someone has a script that /sets a variable and your alias sets it as a different variable name and then the user's script tries to check it later? It would be checking the wrong variable. Also, what happens when a script sets a variable multiple times? Will this just keep making more and more copies of the variable rather than changing it?

As I said, I didn't test it, so maybe these problems are already addressed by the alias. However, if they aren't, then this alias is likely to cause more problems for the "naive" user who runs someone else's script that isn't designed to work hand-in-hand with your alias and just assumes that /set works the normal way.
Making copies of the variable is stoppable if you specify the "-o" when you /set, if the -o is there the script will over-write the variable instead. It's designed to prevent mal functionality of a pre scripted mirc client, if an user tries to change something without knowing what they're doing.

A downside would be the obligatory usage of -o by the author, every time you set variables and do not wish to create copies.

But it's a small price to pay for more security.

I made this animation so you can understand what it's function is:

Link

I appreciate skepticism, it motivates me. I hope the gif is at least understandable.

Last edited by Beau; 10/04/07 06:08 AM.
Joined: Jan 2007
Posts: 1,156
D
Hoopy frood
Offline
Hoopy frood
D
Joined: Jan 2007
Posts: 1,156
First of all Id like to say I appreciate what you are doing. It's a cool idea. What I see from what Riamus is saying is, from a scripters point of view.

I will use blatant examples here, please disregard how stupid it would be to actually write this.
I write:

Quote:
on *:join:#:{
set %nick $nick | set %time time
msg $chan %nick joined $chan at %time
}

on *:text:*.lastnick:#:{
msg $chan %nick joined $chan at %time
}


Ok so I'm not you, I'm just a guy who likes your script and wants to add something to it. Now I have written normal basic code that sets a variable. What happens when that variable is used by you already. I am asking mirc to use %nick but your alias rewrote it to be %nick(2) so I get an error message and it doesn't work. I have to call a variable by its exact name or use $var to find it otherwise it doesnt work. So if I set a variable as %nick and your alias changes the name of it, my code is broken.

Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
/var doesn't work at all. Local variables will never be "stealing" other variables.

The reason /var no longer works is because mIRC calls /set -l internally, and your script overwrites /set, so it calls your script.

You also use /halt at the end which means you cannot do something like //set %x 1 | echo -a %x. This is a very pointless thing to do.

Needless to say this is quite buggy, and I don't think it's worth it. Without meaning to sound mean, you can't make your script immune to user stupidity. If they want to install lots of scripts that conflict with yours, change your code, or edit variables, then they'll find some other way of doing it.

Joined: Feb 2006
Posts: 546
J
Fjord artisan
Offline
Fjord artisan
J
Joined: Feb 2006
Posts: 546
another quite obvious bug, i'm not sure if you realize this but $var() allows wildcards to be used to find variable names. so if you have at least 1 variable set, $var(%*) will be non 0 even though there isn't one named "%*"

of course this can be worked around but then there's the /var issue hixxy mentioned which is currently unsolvable (theres no way to completely alias /set) which, to me, is a huge price to pay for running this script. nice try though ;P


"The only excuse for making a useless script is that one admires it intensely" - Oscar Wilde
Joined: Dec 2002
Posts: 2,031
R
Hoopy frood
Offline
Hoopy frood
R
Joined: Dec 2002
Posts: 2,031
It would be much easier to just prefix your own variables and
don't worry about protecting the variables of other scripts.

%bs.variable for example (bs = beau's script) or choose whatever
prefix you like that is unique to your script so that the chances
of one of your variables being overwritten by the user or by
another script are minimal. With this solution, nothing is broken
but your variables are still protected.

~ Edit ~
If I were to start seeing scripts using this method of protection,
I would start prefixing all my commands with ! to bypass aliases,
which would render your variable protection useless.

Last edited by RoCk; 10/04/07 02:06 PM.
Joined: Apr 2007
Posts: 4
B
Beau Offline OP
Self-satisified door
OP Offline
Self-satisified door
B
Joined: Apr 2007
Posts: 4
An experienced user that knows what they're doing knows that, they would also know not to corrupt the script in such a way it wouldn't work.

The idea behind this is very basic-- people that have absolutely no idea what they're doing wouldn't be able to render a script unfunctional if they accidentally over-write an existing variable.

It's not taking in consideration people that know scripting indeep at all. The "defender" term is against people that damage the script unintentionally, not highjack it to fit their needs.

There might be no way to make mIRC's configuration uneditable to avoid bypasses and change of the interface, unless you encrypt it, I believe.
Originally Posted By: DJ_Sol
First of all Id like to say I appreciate what you are doing. It's a cool idea. What I see from what Riamus is saying is, from a scripters point of view.

I will use blatant examples here, please disregard how stupid it would be to actually write this.
I write:

Quote:
on *:join:#:{
set %nick $nick | set %time time
msg $chan %nick joined $chan at %time
}

on *:text:*.lastnick:#:{
msg $chan %nick joined $chan at %time
}


Ok so I'm not you, I'm just a guy who likes your script and wants to add something to it. Now I have written normal basic code that sets a variable. What happens when that variable is used by you already. I am asking mirc to use %nick but your alias rewrote it to be %nick(2) so I get an error message and it doesn't work. I have to call a variable by its exact name or use $var to find it otherwise it doesnt work. So if I set a variable as %nick and your alias changes the name of it, my code is broken.
Well the script does warn you what the variable got renamed to, doesn't it? If you can write a small remote like that and know what a "remote" is, you would surely know how to make a simple edit such as to add "(2)" to the end of your variables, right?

I pose you this question: To break users' code if they rewrite existing important variables, or to allow users to break your script's functioning?

It is common sense that any successful script would use variables with chariteristic prefixes and sufixes, suchs as %sillyscript.variable, but what if by chance someone does try to over write this anyway, assuming they don't know what they're doing?

This is the purpose of this script.
Originally Posted By: RoCk
It would be much easier to just prefix your own variables and
don't worry about protecting the variables of other scripts.

%bs.variable for example (bs = beau's script) or choose whatever
prefix you like that is unique to your script so that the chances
of one of your variables being overwritten by the user or by
another script are minimal. With this solution, nothing is broken
but your variables are still protected.

~ Edit ~
If I were to start seeing scripts using this method of protection,
I would start prefixing all my commands with ! to bypass aliases,
which would render your variable protection useless.
Yes, but do you comprehend that the script isn't supposed to trap the user?

If the user knows how to bypass variables in such a way it won't interupt the functioning of the overal set of scripts, that's fine.

But some users don't know, and some even accidentally over write variables essential for a prescripted mIRC's scripts, in some rare but possible cases, they even over write things difficult to be over writen such as very specific variables such as "%whatever.tmp".

That's the intent of the script, to nullify any possibility of variable conflict, the fact the user is experienced enough to avoid it doesn't come into this matter.

"%bs.variable for example (bs = beau's script) or choose whatever
prefix you like that is unique to your script so that the chances
of one of your variables being overwritten by the user or by
another script are minimal."

When you said "minimal" you can't say "impossible" can you?

(Currently working on the /var issue, the /halt is already removed.)

Last edited by Beau; 10/04/07 05:42 PM.
Joined: Dec 2002
Posts: 2,031
R
Hoopy frood
Offline
Hoopy frood
R
Joined: Dec 2002
Posts: 2,031
I feel like we kicked your dog or something. Thank you for sharing your script with the scripting
world, but overriding an internal command isn't generally a good idea, especially when it was
proven to break other commands. The user, even the stupid/dumb user, should have absolute
control over everything in mIRC, even if it means breaking your script. When/if that happens
then it's their own fault and hopefully they will have learned a lesson from it. This is why remotes
can be disabled and why commands can be overriden by prefixing them with a ! character. No
script should stop the user from doing something that they want to do and no script should ever
trick the user into doing anything or make the user believe it's doing one thing when it's actually
doing something else. These are also why mIRC script is completely open source. I'm sorry but
that's just the way it is and it is as it should be.

Joined: Jan 2007
Posts: 1,156
D
Hoopy frood
Offline
Hoopy frood
D
Joined: Jan 2007
Posts: 1,156
Quote:
Well the script does warn you what the variable got renamed to, doesn't it? If you can write a small remote like that and know what a "remote" is, you would surely know how to make a simple edit such as to add "(2)" to the end of your variables, right?


This variable name is dynamic. It could be %variable(2) one time and %variable(3) another. I dont care if it warned me. It doesnt change my code. If I write code and when I test it I see a warning, "I rewrote your variable so now your code doesnt work". Should I go rewrite my code for that one dynamically changed variable?

It's a nice idea and a good attempt, please don;t think Im flaming you or putting it down, but the cons definitely outweight the pros in this case. The case that hixxy brought up about not being able to use /var and the halt sealed the deal for me though.

I and I'm sure everyone else appreciates your effort for tackling an issue. I agree with the person who said name your variable so it wouldnt get overwritten. Thats the best idea.

Also, my script has a hash table with switches and such in it. General informationthe script needs, I use this in place of variable many times. Not saying this is THE WAY, but it is a way I can secure that people will not mess up my switches and code.

Joined: Apr 2007
Posts: 4
B
Beau Offline OP
Self-satisified door
OP Offline
Self-satisified door
B
Joined: Apr 2007
Posts: 4
I ponder making it /cmdbox bound, so that issue with the remotes isn't a worry.
Originally Posted By: RoCk
I feel like we kicked your dog or something. Thank you for sharing your script with the scripting
world, but overriding an internal command isn't generally a good idea, especially when it was
proven to break other commands. The user, even the stupid/dumb user, should have absolute
control over everything in mIRC, even if it means breaking your script. When/if that happens
then it's their own fault and hopefully they will have learned a lesson from it. This is why remotes
can be disabled and why commands can be overriden by prefixing them with a ! character. No
script should stop the user from doing something that they want to do and no script should ever
trick the user into doing anything or make the user believe it's doing one thing when it's actually
doing something else. These are also why mIRC script is completely open source. I'm sorry but
that's just the way it is and it is as it should be.
Oh, I don't get neccessarily mad (:, I was just justifying some things/points, if anything I was a bit depressed, but being mad is far from me.

Last edited by Beau; 10/04/07 05:55 PM.
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
I think you're missing the point we're trying to make. Your script is only good if no other scripts are running except ones that USE your script and know how to work with it. If a user loads any other script that uses /set, the script will probably not work because of your script. It doesn't matter that your script tells the user that the variable was renamed with (2) or whatever. You specifically said that your script is designed for users without scripting knowledge. Such a user wouldn't be able to change their script so that it calls the (2) version of the variable, so it wouldn't work properly.

Let's say you have:

Script 1 (# of people who joined the channel):
Code:
on *:join:#: { set %users $calc(%users + 1) }


Script 2 (# of people who used /nick in the channel):
Code:
on *:nick: { set %users $calc(%users + 1) }


* Yes, you'd normally use /inc here, but this is just a quick and easy to see example.

Ok, so your script is supposed to prevent Script 2 from breaking Script 1 since it used the same variable name. However, you have 2 problems here.

First of all, if Script 2's %users is changed to %users(2) when saved and then Script 2 does:

Code:
msg $chan # of users who changed nicks = %users


Then, it will display the number of users who JOINED rather than changed nicks because the SCRIPT still thinks that it's supposed to use %users and not %users(2).

That's just the issue with 2 scripts working against each other. The worst issue is that every single time someone joins the channel or changes nicks, a NEW variable will be created...

User1 joins: %users = 1
User2 joins: %users still = 1, %users(1) = $calc(%users + 1) = 2
User3 joins: %users still = 1, %users(1) still = 2, %users(3) = $calc(%users + 1) = 2
etc.

And, as hixxy pointed out, /var no longer works with your script installed.

You say that if you want the variable overwritten, that the script should just use -o. That's fine if the person writing the script plans to use your script and so uses -o everywhere or if the user of the script knows to change all of those /sets to have -o. Otherwise, your script will just break every other script out there.

It's a good idea, but a better solution would be to have your script check if the variable exists and then just tell the user that you're overwriting the variable so the user knows that it was overwritten and can ask someone about it if he/she doesn't know how to see if it's ok. Now, that's still not a great thing as variables are overwritten often in scripts. But it's at least not changing anything... just echoing the information.

The suggestion of using unique variable names is a good one and should always be done for global variables regardless of what you're doing. Yes, it is possible that some other script could use the same variable name as you are using. If it's unique enough, then that's unlikely, but it's possible. That doesn't mean you should really worry about it.

If you are really concerned about variables in your script being overwritten even if you have unique variable names, then set 2 different variables to the same value and whenever you get data from the variables, check both to see if they still have the same value. If not, output an error and halt your script. Then, if the script halts with an error, you know that the variable was changed by another script and you can look for the problem. If you wanted to take it beyond just a message saying:
Quote:

%variable was changed by a script other than myscript.mrc. You may have a conflict between myscript.mrc and another script. Halting.


then you could also have your script (an alias) check all loaded scripts for the variable name that you're having issues with and then you can be more specific in your output:

Quote:

%variable was changed by a script other than myscript.mrc. You may have a conflict between myscript.mrc and another script. Halting. The following script(s) may conflict with myscript.mrc: yourscript1.mrc, yourscript2.mrc.


You get the idea. Personally, I wouldn't do anything other than use unique variable names, but that's a possible solution if you really want to avoid problems without breaking all other scripts that are loaded.


Invision Support
#Invision on irc.irchighway.net
Joined: Jan 2007
Posts: 1,156
D
Hoopy frood
Offline
Hoopy frood
D
Joined: Jan 2007
Posts: 1,156
Beau, dont be sad man. I think everyone appreciates the idea and the work you put into it. The reason there are forums is so we can see things from other perspectives. I miss things all the time and if I'm lucky, other people point them out to me.


Link Copied to Clipboard