I want to shout out Mouseclone for letting me know there was a problem with this site. I was contacted on Friday about an alert that was raised to him that I had a possible iframe hijack on my site. Not really knowing what he was talking about I quickly scanned my source code for the exact iframe source that he provided. Not finding anything I dismissed it as many users of SocialSpark visit me and he possibly confused me with someone else.

 I did find today that in fact a database injection had been done and the iframe was there. My mistake was that I only hit the home page and the iframe was on the previous page. The iframe source refers to 61.155.8.157 and after some examination of the obfuscated JavaScript, redirections were discovered. I’ve contacted the server abuse department and will follow up if these people are not shut-down.

Welcome to the interwebs. This is the second time I have been hijacked in the same way. This is a new theme that I have gone through and can not find malicious php code, and since it’s in the admin section I can only assume that it’s a Wordpress security problem. This however is the second time I’ve found hijacked stuff in my database!

While I have gone through every line of code in both this theme and the access logs for this site I can not find how this is happening. Which make me very cranky as it’s happening.

My apologies to anyone who has gotten alerts. Systems are in place to track and prevent these from happening anymore. I hate Wordpress 2.5 (I just set up a site using it) but if it’s a 2.3 problem I’ll have to upgrade.

Tags: hijack, JavaScript, SocialSpark

With plugins, widgets, and what-not’s every JavaScript author is vying for space on a web page, whether their own or someone elses. How then to keep the funciton literal names from colliding with other authors, or even previously written code? Writing JavaScript strictly with global functions really places you in a situation that someone may use the same name and make your function useless, and ultimately your entire program.

This is where namespacing your JavaScript reduces the risk of anyone colliding with your code. Quite simply namespacing in JavaScript is just as simple creating an object and attaching the functions to that object, the JavaScript Prototype scope, gotta love it. Yes, you are building a JavaScript object that sets all the methods apart from anything else someone would create. So this object can, and should, contain any needed functions that it needs to operate.

The actual naming convention of the object is really up you. I personally like to namespace of the object intent, Browser. (Browser detection object), TR. (functions relating to the general javascript of Tech Raving). The real intent is to use a name that someone else may not use. Take Browser for instance, what are the chances that someone else could use that for an object or function name? Probably pretty good. BrowserSJK as a name doesn’t really look good but now what are the chances that someone will use that!

To actually create a namespace object is relativly simple:

var TR = {
    method1 : function() {
        //Do stuff here
    },
    method2 : function() {
        //Do stuff here
    }
}

So now you can use TR.method1().

That’s good for a start but what about variables you would normally need. Easy enough to set up and use and gain access to:

var TR = {
    attribute1 : “hello”,
    attribute2 : “world”,

    setAttribute1 : function(temp) {
        this.attribute1 = temp;
        this.method1();
    },
    method1 : function() {
        //Do stuff here
    },
    method2 : function() {
        //Do stuff here
    }
}

TR.setAttribute1(”test”);

The difference in namespacing this way as opposed to just writing the variables and functions is the attachment to the TR object and the use of the this keyword to make the object reference itself in the executable scope. Here there be dragons when global scoping varibals and functions because of naming collisions, although it’s easy enough to access them if no collision occurs. Namespacing protects the variables and methods by wrapping them in an object, yet some care is needed by accessing them through the Namespace name, and using the “this” keyword for access outside of the method, yet referencing within the object namespace. Sounds complicated I know, it’s a prototype thing, but until you attach events to dynamically created html elements it’s really straight forward.

So what’s a developer to do if they have existing code that has either conflicted or just needs a little love and refactoring? That’s simple as well just create an object and then prepend all the methods and varibles with the Namespace.

old code:

var myVar1 = “hello”;
var myVar2 = “world”;

function method1() {
    //do Somtehing;
}

new code:

var myObj = new Object();

myObj.myVar1 = “hello”;
myObj.myVar2 = “world”;

myObj.method1 = function(temp) {
    this.myVar1 = temp;
}

myObj.method1(”test”);

Now the new code is protected from generalization of naming. Unless you have hundreds of lines of code the refactor should go quickly. If you have hundreds of lines of the old code I would highly suggest breaking into related objects using the same namespace approach.

JavaScript used to be authors writing code for their own sites in order to help acheive some dynamic capabilities. Maybe specialized libraries, such as menu’s or link generators where “given” out, but really only one was used on a publishers site. Now a days with the many widgets given out it’s quite common for publishers to have many third party JavaScripts and not from the same author. Namespacing is a way to protect your code as an author from the other authors.

As web 2.0 grows in popularity, it’s important for us developers to ensure that our code is tested and works even in the event of failure on another party.

Tags: JavaScript, Programming, web 2.0