Forums Feature Suggestions Switch to prevent 2nd eval of /timer, /scid, /scon

It would be extremely useful if /timer, /scid, and /scon all supported a switch that prevented the second evaluation step for their respective 'command' parameters. There are a lot of occasions where people don't need that evaluation and then don't consider the repercussions of using certain strings with it - often resulting in exploitable code. A switch to turn that functionality off would provide a simple means to avoid those security issues.

Off by default would be better, with the switch to turn it on.

In an ideal world yes. Although then there's the backwards compatability issues...

In this case though I think it might be worth the trouble to break compatability for the security gain.

Good suggestion, and indeed, the switch should turn the double evaluation off for compability

Well this whole thing, along with the uproar in the other thread, is all about security. Well, off by default would be the more secure thing to do. Breaking scripts is irrelevant.

Breaking 1/2 or 2/3 of (more complex) scripts is irrelevant? I don't think so... At least, it would be one of the most intrusive changes to MSL so far.

Indeed I second the initial suggestion (allowing 'easy' non-evaluating timers), but you cannot punish existing (and most likely: secure) script(er)s for our own failures. At times, I'll be running into this issue myself, as I did in the past, and without any doubt I used and posted 'non-waterproof' code on these boards before.

To me, the issue is not that we (the scripters) did not know how to escape this possible exploit (or source of error at least) or aren't aware of it (this behaviour as well as possible misuse are known for a long time), but we simply do not think of it in this or that situation. Raising the question: would we think of using this hypothetical switch in that situation?
As stated, solving this 'dilemma' by breaking tons of existing addons and scripts is not acceptable to me.

And because of this, we should rethink our usages of timers/sc** cmds, thus blaming no one but ourselfes for these errors, and try to make better of course. At heart it's not mIRCs fault, but ours.

Imho, a switch could indeed help unexperienced scripters (as long as there will be an eye-catching warning added to the help file too), but cannot substitute our own awareness.

I agree with that. More education on the dangers of this in the help file would definately be a good idea.

I'd still like to see the use of directives to tell the interpreter how to behave.

#!evalonce on

alias t { .timer blah de blah }

#!evalonce end

That's bulky. What if you only want that to happen in one line of your script?

alias t {
#!evalonce on
timer ...
#!evalonce end
scid ...
}

Wouldnt work (mIRC cant differentiate directives inside {} because theyre valid commands). It also requires you to make the alias on multiple lines.

I think it should just default to the eval-once thing and a switch should change the behaviour to the old format.. or the other way around.

It could just as well be a comment.

; -opt EVALONCE on

The reason I suggest something like this is so it could be used to control other script options, eg. the "identifier warning" option that is so far only settable by the remote editor.

Even if it did break some scripts that required double evaluation, it would be very easy for the people writing/using such scripts to do a Replace All on "timer" with "timer -whatever_switch". Or, so you don't just replace everything without knowing what's going on, you can just fine each instance and replace them. I could do that in Invision, which is a fairly large script easily in under half an hour... probably under 10 minutes. That's far less intrusive than other changes that require a lot more time to make adjustments for.

I'd support this switch with it defaulting to single evaluation.

You also can't use comments on a single line, so that wouldnt work either.. why not just make it a /command?

/eval off | .... | /eval on

and potentially have it auto-reset when the script finishes processing.

I don't see what directives or comments give you that a command does not..

Yes you can

; This is a single line comment

/*
This is also a single line comment
*/

You are right about the command thing, I just think a directive would make it more uniform with other languages.

command | ; not a comment | ... <- edit: I was wrong, this is treated as a comment by ignoring the command. This is generally a bad idea though, since the help file states ; comments should be "at the start of a line".

commands make it more uniform with mirc, which is what matters. A comment in the case of the above is nearly equivalent to any command anyway.

Old, I know... I just thought I'd point out a use for $encode/$decode:

/timerNAME 1 1 $!decode( $+ $encode(dosomething $1-,m) $+ ,m)

It's the cleanest alternative I could come up with.