JavaScript Server Programming (object attribute enumeration should avoid the problem of prototype contamination)

In the previous article, we discussed the ES3 and ES5 scheme of object attribute enumeration in JS development and gave a set of common tool functions, in fact, there are still many problems in the real application of enterprise development. This article would like to further explore the problem of prototype pollution based on the previous article. Because of the inherent weakness of JS, there is a big "story" behind the prototype pollution, and some of the plots in our article will be covered later.

Problem

the previous discussion uses inch operator to detect the existence of a property in an object, but a problem is also found through the examples cited, such as:

Console.log (' "id" in Contacts: ', "id" in Contacts);

the output of the result is true . This indicates that the in operator not only searches the property of the current object, but also searches along the object's prototype chain.

based on the previous analysis of attribute inheritance, it is possible to know JS objects in an object always work in an inherited way, even if an empty object literal is inherited Object.prototype a large number of properties. Therefore, the following test results are expected from us:

var pol={};

Console.log ("Hi" in Pol); False

Console.log ("ToString" in Pol); True

Console.log ("ValueOf" in Pol); True

Console.log ("constructor" in Pol); True

Console.log ("__definegetter__" in Pol); True

Console.log ("__definesetter__" in Pol); True

Console.log ("__lookupgetter__" in Pol); True

Console.log ("__lookupsetter__" in Pol); True

Console.log ("hasOwnProperty" in Pol); True

Console.log ("isPrototypeOf" in Pol); True

Console.log ("propertyIsEnumerable" in Pol); True

Console.log ("toLocaleString" in Pol); True

and in ES5 used in Object.prototype in the hasOwnProperty method avoids the problem above because it retrieves only the object's own properties, including non-enumerable properties ( ES3 does not define such a concept).

further

if the object itself has an own property hasOwnProperty , what should be the situation? Refer to the following code:

var o={};

O.hasownproperty= "*********";

Console.log (O.hasownproperty ("Alice");

When you run the test, you see a run-time error as shown:

650) this.width=650; "title=" Untitled. jpg "src=" http://s3.51cto.com/wyfs02/M00/6D/28/ Wkiom1vdefzzyfeeaafdskcrbam427.jpg "alt=" Wkiom1vdefzzyfeeaafdskcrbam427.jpg "/>

In this case, the expert's advice is "the safest way is not to make any assumptions". As a result, we can extract the hasOwnProperty method in any secure location ahead of time, and take advantage of the lexical scope features of an immediately executed anonymous function to achieve the following solution:

(function Testownproperty () {

//var Hasown=object.prototype.hasownproperty; You can also use the following more concise way

var Hasown={}.hasownproperty;

var dict={};

Dict. alice=12;

Console.log ("------------");

Console.log (Hasown.call (dict, "hasOwnProperty"));

Console.log (Hasown.call (dict, "Alice"));

dict.hasownproperty=100;

Console.log ("-------------");

Console.log (Hasown.call (dict, "hasOwnProperty"));

Console.log (Hasown.call (dict, "Alice"));

Console.log ("---------------");

})();

so, regardless of the object's hasOwnProperty method is overwritten, all of the above scenarios work correctly. It is worth noting that many well-known JS libraries are using the above technologies.

This article is from the "Green Peak" blog, please make sure to keep this source http://zhuxianzhong.blog.51cto.com/157061/1653484

JavaScript server programming (should avoid prototype contamination in object attribute enumeration)