Comment On Eval This!

try {eval(fist)}catch(e){delete}

Ugh, that style of coding looks somewhat catching...

FIST@!!!@!

b0bg0ats3:

FIST@!!!@!

Actually, that would be "TURD@!!!@!", wouldn't it?

Normally I can find a way to see what the coder was thinking, but I just can't find ANY justification for this method of doing this.

Well, that would make debugging easier, right? All you need to do is add alert(jStr); before each line you want to debug, and you know exactly where you are in the code! Brilliant! Unless you need to eval("alert(" + jStr + ")");

for(i=0;i<code.length;i++)
{
eval(code[i]);
}

I'm afraid it wouldn't work as intended...

I'd Evaluate that as being of poor quality.

I think I almost actually said WTF out loud reading that! It makes it slower, harder to read, and more fragile all at the same time, and all with no benefit what so ever.

That is worse than ANYTHING I have ever written, and I have been coding since 1977.

Hmmm... is that a code injection vulnerability I smell?

About a year ago, I inherited a Perl script that was written a lot like this. Basically it had this structure:

eval
{
# Tons of Perl code
}

if ($@) {
# Handle error.
}

He was using it as a try/catch block for Perl. The thing is, the "Tons of Perl code" had plenty of error checking and handling that he could have done for it without the eval and all this monstrosity did was make it nearly impossible to debug.

Won't someone please think of the maintenance programmers?

bstorer:

Hmmm... is that a code injection vulnerability I smell?

No... not really in that case.

Maybe the programmer assumed that javascript had some sort of difference with late/early binding, and window.opener, since it may not exist, has to be evaluated as a string, so that it can be bound. Of course, this is silly, but it's the best I can come up with.

On another note (OT), while I'm here, what's the point of assert(0 == 1) in a language that supports throw? I just saw it in some of the code I'm debugging.

Addendum (2007-08-08 10:52):
Oh, wait, I skimmed over the code, not noticing the CompanyName. So there's a possibility for code injection, but it's Javascript. You'd only be hurting yourself.

Grant:

I think I almost actually said WTF out loud reading that! It makes it slower, harder to read, and more fragile all at the same time, and all with no benefit what so ever.

That is worse than ANYTHING I have ever written, and I have been coding since 1977.

It does have a benefit!

What do you think would happen without the eval when PolicyNumber does not exist?!

Didn't anyone tell you that this is the only way to be sure execution proceeds normally when the element doesn't exists?!

Another big WTF is using document.all to access an element.

...to quote Dr. Janosz Poha from Ghostbusters 2:

"Everything you are doing is bad...I want you to know this."

[quote user="qsdfqsdfsfsdfsqdfffffffffffffff"][quote user="Grant"]What do you think would happen without the eval when PolicyNumber does not exist?!

Didn't anyone tell you that this is the only way to be sure execution proceeds normally when the element doesn't exists?!
[/quote]

False.

if(elementReference) { /* do something */ } // Works nicely in JS.

I'm not that familiar with scripting languages, what does eval() do?

SomeCoder:

About a year ago, I inherited a Perl script that was written a lot like this. Basically it had this structure:

eval
{
# Tons of Perl code
}

if ($@) {
# Handle error.
}

He was using it as a try/catch block for Perl. The thing is, the "Tons of Perl code" had plenty of error checking and handling that he could have done for it without the eval and all this monstrosity did was make it nearly impossible to debug.

Won't someone please think of the maintenance programmers?

eval {} is the generally accepted way of providing try/catch functionality in Perl. The only WTF here is the "Tons of Perl code" being evaluated at once.

Quite obviously jStr1 through 5 (and 4) are filled in with a Server Side Include mechanism for maximum flexibility and code security. After all, it is against company policy to release source code files.

[quote user="Pilum"][quote user="qsdfqsdfsfsdfsqdfffffffffffffff"][quote user="Grant"]What do you think would happen without the eval when PolicyNumber does not exist?!

Didn't anyone tell you that this is the only way to be sure execution proceeds normally when the element doesn't exists?!
[/quote]

False.

if(elementReference) { /* do something */ } // Works nicely in JS.[/quote]

One word: sarcasm.

Since the code is defined out of order (5 before 4), I am sure that it would never do what was intended, and it would be a very difficult thing to track down.

I guess the person thought that you must use eval to assign variables (he referenced them without the eval just fine).

This was pretty common back in the day. It's still pretty common, actually. It's simply people writing code that don't know how to program.

Basic: on error resume next
JS: eval(...);eval(...); ...

What else is new?

Michael:

eval {} is the generally accepted way of providing try/catch functionality in Perl. The only WTF here is the "Tons of Perl code" being evaluated at once.

Not really. This looks like a fallback handler that is used to deal with unexpected errors in a more graceful way (e.g. logging it and reporting "sorry, can't do that" instead of splatting plain text in the middle of something in a different format). In normal operation of such code, nothing ought to trigger the fallback operation.

If it's not being used that way, it's a WTF?! of course.

Of course if you use try/catch it is not really error checking. It is error chucking.

My browser already remembers all the captchas...

Pilum:

Another big WTF is using document.all to access an element.

getElementById works only since IE6.

Ok, I don't pretend to know much about Javascript but I thought Eval() just reads text and converts it into script. In that case, why would anyone support what he's doing given that they are "company names"? Does Javascript not recognize strings that are just in quotes?

bstorer:

Hmmm... is that a code injection vulnerability I smell?

Actually, all JS is injection vulnerable. You can redefine any function, add new ones, and execute any code on any website, but, as someone has already pointed out, only on your client.

Cloak:

Pilum:

Another big WTF is using document.all to access an element.

getElementById works only since IE6.

If anyone's still using IE5.5, that's an even bigger WTF?

(BTW, I could've sworn the RSS feed didn't have ads before...)

makomk:

If anyone's still using IE5.5, that's an even bigger WTF?

OP:

...some old JavaScript code...

edit : and I don't see any ads in the feed (using netvibes)

It reminds me of someone who uses Table-Oriented Programming. Where everything is done through evals as the actual 'code' is stored in tables. Not making this up. Look for it.

I'm disappointed. I thought the title read "EVIL this!" :(

Cloak:

Pilum:

Another big WTF is using document.all to access an element.

getElementById works only since IE6.

IE has supported getElementById since version 5. That's since March 1999.

   companyName = unescape(companyName);

   if (window.opener){

      jStr1 = "window.opener.document.all.IcompanyName.value = trimString(unescape(companyName))"

OK, I've never written a line of Javascript in my life, but isn't that unescaping companyName twice (thus requiring companyName to look like "Smith &amp;amp; Wesson" or "Coca%252DCola")? Or are the two companyName variables in different scope or something?

Asymmetrical escaping and unescaping always makes me reach for the nearest loaded firearm.

durnurd:

bstorer:

Hmmm... is that a code injection vulnerability I smell?

No... not really in that case.

Addendum (2007-08-08 10:52):
Oh, wait, I skimmed over the code, not noticing the CompanyName. So there's a possibility for code injection, but it's Javascript. You'd only be hurting yourself.

Not quite. Ever heard of XSS?

Say, for example, that CompanyName, in this case, is taken from somewhere on the page. Consider also, that perhaps CompanyName is user entered data, and that users can view CompanyNames entered by other users.

A malicious user could then enter a CompanyName with some javascript in it to, say, forward the viewer's session cookie to the malicious user's website, and he could then hijack the user's session. If the hijacked user happens to be some sort of site superuser, then that's just a bonus.

Granted, this requires several layers of vulnerability on top of the eval(), but the moral is simple: don't eval un-filtered user input.

jread:

Ok, I don't pretend to know much about Javascript but I thought Eval() just reads text and converts it into script. In that case, why would anyone support what he's doing given that they are "company names"? Does Javascript not recognize strings that are just in quotes?

The evil eval() executes whatever script you put into it. The difference between

n = 1;

and

eval("n = 1;")

is that the eval() takes longer.

If I needed to do this sort of thing, I'd make sure window.opener exported functions that could fill its own form fields, so that the child window didn't have to know so much about what was going on upstream.

CAPTCHA: sanitarium (yes, for the person that wrote the original scripting)

Main exception: Cross-site scripting, where someone ELSE tinkers with the Javascript on your client, say, by successfully putting some javascript into their sig file on a web forum or something.

They could thus inject code into other people's browsers. For example, the code could scan the page to see if the victim is currently logged in, and then go make fraudulent posts.

That's one of the good reasons to make users confirm major actions (e.g. account password change) with re-entering their password even if they are already logged on.

Michael:

SomeCoder:

About a year ago, I inherited a Perl script that was written a lot like this. Basically it had this structure:

eval
{
# Tons of Perl code
}

if ($@) {
# Handle error.
}

He was using it as a try/catch block for Perl. The thing is, the "Tons of Perl code" had plenty of error checking and handling that he could have done for it without the eval and all this monstrosity did was make it nearly impossible to debug.

Won't someone please think of the maintenance programmers?

eval {} is the generally accepted way of providing try/catch functionality in Perl. The only WTF here is the "Tons of Perl code" being evaluated at once.

Perl eval {}; if ($@) {...} catches die(..); events. It should only be used as a try/catch to report run-time errors that can't be checked with if (..) {}, such as network failure.

# No eval: division by zero
if ($denom != 0) { $q = $num/$denon } else { $q = 0; }

# Use eval to catch DBI errors on DB server.
eval {
$dbs = $db->prepare("SELECT * FROM TAB1");
}
if ($@) {
print STDERR "DB server can't prepare SQL\n Reason: $@\n";
}

Notice that $@ reports the DBI error. So, debugging is still quite nice!

The Real WTF is that the coder used eval() on nearly each line of code, some within a try/catch and others without.

s0be:

Normally I can find a way to see what the coder was thinking, but I just can't find ANY justification for this method of doing this.

Payed by line?

Captchs-anti-captchs-remover: ninjas

I don't know Java, but the coder might have thought of using the evals as a way, however misguided, of abstracting / simplifying the try / catch blocks so they would fit on a single line.

Zygo:

   companyName = unescape(companyName);

   if (window.opener){

      jStr1 = "window.opener.document.all.IcompanyName.value = trimString(unescape(companyName))"

OK, I've never written a line of Javascript in my life, but isn't that unescaping companyName twice (thus requiring companyName to look like "Smith &amp;amp; Wesson" or "Coca%252DCola")? Or are the two companyName variables in different scope or something?

Asymmetrical escaping and unescaping always makes me reach for the nearest loaded firearm.

You're looking at it backwards. escape("Coca-Cola") would return "Coca%2DCola", thus escape(escape("Coca-Cola")) would give "Coca%252DCola"

Unescape reverses the process. So if it was originally "Coca%2DCola", unescaping the first time will change it into "Coca-Cola", and the second time will do nothing.

nickfitz:

Cloak:

Pilum:

Another big WTF is using document.all to access an element.

getElementById works only since IE6.

IE has supported getElementById since version 5. That's since March 1999.

The document.forms.elements collections predates both and are still the most reliable and efficient way of accessing forms elements. And that's just two of several collections available.

As it is, getElementById is highly overused.

I had a similar problem with a PHP "program" I inherited from the old webmaster a couple jobs ago. Basically, she would build a string of executable PHP code, save it as a variable, and then eval() it.

"..wait, wait....Joy, why are you doing this?!? You're IN PHP!"

"oh..I guess that makes more sense."

She left 2 days later and I basically had to rewrite the entire thing it was so bad.

//How to call a function in javascript



var lines = my_function.toString().split(/\n/);



for (i=0;i< lines.length;i++) {

  try {

    eval("try{"+lines[i]+"}catch(e){}");

  } catch(e) {

  }



}

Carburizer:

I don't know Java, but the coder might have thought of ...

You don't know Java and you don't know javascript.
This here is javascript.
Java != Javascript - or to speak more on topic:
eval (Java != Javascript) == true.

that's one reason newly employed programmers would want to resign

not only that
eval in js is 'global'

function x(){
var a = 1
}

function z(){
eval("var b = 1")
}

the var b will be global

I can't believe no-one has noticed the real WTF. This is JavaScript people, not Java. Please press Enter before starting a new block.

document.getElementById has been available a long time, but is iffily implemented in IE up to and including IE6. Specifically, IE will actually retrieve the NAME rather than the ID.

<input type="text" name="name" id="firstName">

<input type="text" name="company_name" id="name">

<script>

alert(document.getElementById('name').value);

</script>

IE and firefox will return different values. Yay. A common trap.

As for the reference to Table-Oriented Programming, I've seen that too. Everything from queries (quite common) to javascript to blocks of PHP stored in various tables for processing. It's a good way to store things because.... um... Nope. I got nothing.

Oh. And yeah. Java != Javascript. That bugs me.

CAPTCHA: seriously... who cares?