intercepting javascript alert()..? is it acceptable?

Question

Hi,

I just found we can intercept the javascript alert() native call and hook the user code before the actual execution. check out the sample code..

  function Test(){
    var alertHook=function(aa){
     this.alert(aa);
    }

    this.alert("aa");
       this.alert = alertHook;
    alert("aa");
  }

so everytime i call alert("aa") is been intercepted by my alertHook local function. But the below implementation with the small change does not work.

  function Test(){
    var alertHook=function(aa){
     alert(aa);
    }

    alert("aa");
       alert = alertHook;  //throws Microsoft JScript runtime error: Object doesn't support this action
    alert("aa");
  } 

it throws Microsoft JScript runtime error: Object doesn't support this action.

I dont know how this.alert = alertHook; let me intercept the call, but alert=alertHook; not.??

So i assume using this to intercept any native js methods.? is that right?

And is that acceptable? because this way i can completely replacing any native JS calls with my own methods??

UPDATE:

I asked is that acceptable? because how this is a good approach having eval() and letting users to replace native function calls?

And its responsibility of a language to protect developers from the misleading features, replacing the native js calls in a window level(or in a common framework js file) would crash the whole system.. isn't it??

i may be wrong in my opinion because i dont understand the reason behind this feature..? I never seen a language that let developer to replace its own implementation..

Cheers

RameshVel

Answer 1

Depending on how Test(); is being called, this should be the window Object.

I believe Microsoft allows overwriting native JS functions only by specifying the window object.

So window.alert = alertHook; should work anywhere.

---

is it acceptable?

Yes it is. This is a major strength for the flexibility of the language, although I'm sure there's better alternatives instead of overwriting native behavior.

Overwriting native JavaScript functions isn't really a security issue. It could be one if you're running someone elses code that does it; but if you're running someone elses code there's a lot of other security issues you should be concerned about.

Answer 2

In my opinion, it never is good practice to redefine the native functions. It's rather better to use wrappers (for instance, create a debug function that directs its output to alert or console.log or ignores the calls or whatever suits your needs).

As for why JScript throws an exception with your second example and not the first one, it's easy. In the first example, you create a property called alert in your local scope, so when you refer alert you'll be referring this.alert rather than window.alert. In the second example, the alert you're referencing is the one from window, so assigning a different function to it will fail.

Answer 3

And its responsibility of a language to protect developers from the misleading features, replacing the native js calls in a window level(or in a common framework js file) would crash the whole system.. isn't it??

Not true, replacing the native call only hooks into it, replaces it: it does not rewrite the native at all. Crashing the "whole" system; JavaScript runs in a Virtual Machine, it's interpreted, so the chance of crashing the "whole" system (i.e. Blue Screen of Death?) is very very small. If so: it's not the programmers fault, but the implementation of JavaScript which is causing the error.

You can consider it as a feature: for instance, if you load a JavaScript from someone else's hand, you can reimplement some functions to extend.

Protection to the programmer is like keeping a dog on the leash: only unleash it, when you trust the dog! Since JavaScript runs in a Virtual Machine, any programmer can be unleashed -- if the implementation is secure enough, which it is (most of the time?)