I'm trying to read a JSON array. Every time i try to read the array/value by passing JSON object key like this-
json[key]
It shows a Eslint error-
[eslint] Generic Object Injection Sink (security/detect-object-injection)
I understand its a security warning because the key may not exists. But how do i resolve this warning? Is there any easier way to read the Json object. My plan is to pass the "key" to the function and read the json based on the key.
You are searching for an ES lint error fix:
Here is the syntax for it
json [`${key}`]
Example:
const obj = {
eventName: 'Music event',
landingPic: 'landing.jpg',
eventPic0: 'pic0.jpg',
eventPic1: 'pic1.jpg',
eventPic2: 'pic2.jpg',
eventPic3: 'pic3.jpg',
artist: 'Elie'
};
// array of keys which need to be read
const arrayOfKey = ['landingPic', 'eventPic0', 'eventPic1', 'eventPic2', 'eventPic3'];
// let's read the value by a key in array
arrayOfKey.forEach( key => {
const value = obj[`${key}`];
console.log(value);
});
There is a good answer here. In general this rule is for paranoiac and the article to which everyone appeal is a mislead. So the best answer, I would say is to turn this rule off, if you can for sure.
And another answer in the comments refers to eslint contributor answer that this rule is pretty false positive prone and more for human to audit a codebase(warning level) rather then give an error in a CI. So I would say you can totally ignore this rule or turn it off.
If you cannot turn it off or ignore, you can disable the eslint for line with comment that it's a false positive or use some interpolation as mentioned in other answers.
And finally, in order to destroy any doubts, the answer from creator of the rule:
"I'm the original author of this rule - for a bit of context, it was originally written as an assistive tool for manual code reviews, to be
used with the eslint plugin for VS Code. I would recommend disabling
it for other use cases, as it's just going to be far too noisy."
Unsure why, but typecasting the access parameter silences the error. Guessing this has something to do with sanitation being able to prevent pollution.
const myThing = myObj[String(key)]
const myThing = myObj[key as string]
What its trying to say is that using this notation:
You are able to modify even prototype properties of the object which is considered dangerous
By being able to modify everything, you are also able to modify the constructor (method/function) so it may be injected and then exploited.
The subject is described analytically here, providing a simple example:
https://web.archive.org/web/20150430062816/https://blog.liftsecurity.io/2015/01/15/the-dangers-of-square-bracket-notation
Related
I'm trying to read a JSON array. Every time i try to read the array/value by passing JSON object key like this-
json[key]
It shows a Eslint error-
[eslint] Generic Object Injection Sink (security/detect-object-injection)
I understand its a security warning because the key may not exists. But how do i resolve this warning? Is there any easier way to read the Json object. My plan is to pass the "key" to the function and read the json based on the key.
You are searching for an ES lint error fix:
Here is the syntax for it
json [`${key}`]
Example:
const obj = {
eventName: 'Music event',
landingPic: 'landing.jpg',
eventPic0: 'pic0.jpg',
eventPic1: 'pic1.jpg',
eventPic2: 'pic2.jpg',
eventPic3: 'pic3.jpg',
artist: 'Elie'
};
// array of keys which need to be read
const arrayOfKey = ['landingPic', 'eventPic0', 'eventPic1', 'eventPic2', 'eventPic3'];
// let's read the value by a key in array
arrayOfKey.forEach( key => {
const value = obj[`${key}`];
console.log(value);
});
There is a good answer here. In general this rule is for paranoiac and the article to which everyone appeal is a mislead. So the best answer, I would say is to turn this rule off, if you can for sure.
And another answer in the comments refers to eslint contributor answer that this rule is pretty false positive prone and more for human to audit a codebase(warning level) rather then give an error in a CI. So I would say you can totally ignore this rule or turn it off.
If you cannot turn it off or ignore, you can disable the eslint for line with comment that it's a false positive or use some interpolation as mentioned in other answers.
And finally, in order to destroy any doubts, the answer from creator of the rule:
"I'm the original author of this rule - for a bit of context, it was originally written as an assistive tool for manual code reviews, to be
used with the eslint plugin for VS Code. I would recommend disabling
it for other use cases, as it's just going to be far too noisy."
Unsure why, but typecasting the access parameter silences the error. Guessing this has something to do with sanitation being able to prevent pollution.
const myThing = myObj[String(key)]
const myThing = myObj[key as string]
What its trying to say is that using this notation:
You are able to modify even prototype properties of the object which is considered dangerous
By being able to modify everything, you are also able to modify the constructor (method/function) so it may be injected and then exploited.
The subject is described analytically here, providing a simple example:
https://web.archive.org/web/20150430062816/https://blog.liftsecurity.io/2015/01/15/the-dangers-of-square-bracket-notation
im trying to learn gjs and having a few questions which i think are basic about ParamFlags.
I'm creating a subclass and trying to use GObject.ParamFlags.CONSTRUCT_ONLY | GObject.ParamFlags.READABLE for one of the parameters. The use case being what it sounds like, being able to set it only during construction and later being able to read it. I'm declaring it like:
magic_word: GObject.ParamSpec.string(
"magic-word",
"Magic word",
"My magic word",
GObject.ParamFlags.CONSTRUCT_ONLY | GObject.ParamFlags.READABLE,
"magicword default value"
),
But this throws the following error during module loading.
GLib-GObject-CRITICAL **: 14:18:53.750: validate_pspec_to_install: assertion 'pspec->flags & G_PARAM_WRITABLE' failed
It still allows the program to continue execution though.
It seems the only way to get this error to stop is to also give it the WRITABLE or READWRITE flag and perhaps implement the desired behavior through getter/setter. But then the purpose of CONSTRUCT_ONLY seems lost. What am I missing?
G_PARAM_CONSTRUCT_ONLY means a property can only be set during construction, implying that the property must be writable. In other words, CONSTRUCT_ONLY is simply a constraint on WRITABLE.
The merge request adding JS-level support for G_PARAM_CONSTRUCT_ONLY might help clarify how this works in GJS: https://gitlab.gnome.org/GNOME/gjs/-/merge_requests/377. Keep in mind this was only merged in November 2020.
I'm learning Javascript and I wrote the following code:
if (mystring.len > 0) {
// do stuff
}
I accidentally used .len instead of .length. To my surprise, no error was raised. mystring.len returned undefined and this made the comparison fail but the code kept right on running. I would prefer an actual error to be raised so I can fix the code. Adding "use strict" didn't help, nor did jslint.
I know there are ways to actively check whether or not a property exists, but that's not what I'm looking for. I want Javascript to tell me when I've made a typo in a property name.
Is there a way to cause Javascript to give an error in this case?
Nope - that is how JavaScript works and it's incredibly useful. Who is to say that checking len is something that needs fixing? Consider:
if(mystring.len === undefined) {
mystring.len = "Test";
}
The best you can do is to simply check that the thing is defined before using it:
if(mystring.len !== undefined) {
}
I appreciate the strangeness, and how it doesn't feel robust (having originally come from a C# background) but there isn't a lot you can do unfortunately. The fact that JavaScript is case sensitive makes this even more frustrating. You will learn to live with it though!
If you really really wanted to run some static analysis then you could considering creating a transpiler (e.g. Babel) extension to run this sort of analysis - but it would get really difficult if you ever expected something to be undefined which I find is common place.
edit
Here's a real example that I'd use where undefined is useful. I'm working with a library that needs to move stuff from one location to another. It can't do that unless the original location has been specified, so I might write something like the following, initializing values if I don't have them for some reason:
function update(node) {
if(node.x === undefined) { node.x = 0; }
node.y = node.y || 0; // This is the shorthand way I'd actually write it
// Do some other stuff
};
"use strict" (in my experience) is used so that variables that aren't explicitly declared/instantiated that are then referenced will throw errors (else, JS would just make a new var on the fly). So that wouldn't help here.
This sounds like an error that would typically be picked up by a compiler in other languages, but since JS is interpreted, you won't have that kind of explicit error checking unless you're in a beefy IDE. Are you using a text editor or something to write JS?
Thats not the way JavaScript considers your above code. Every variable in JS is an object. So, when you do mystring.len, its actually trying to access the len property of mystring obj and when it doesn't find that property, it will return undefined - which is how it should be. Thats why you will not be able to find any error using JSLint.
Just to give you an example -
var myObj = {name: 'Hello', id: 1};
console.log(myObj.name); // Returns 'Hello'
console.log(myObj.text); // 'undefined'
In order to prevent such code from giving you any errors, you can easily use the hasOwnProperty() method like follows-
if(myObj.hasOwnProperty('text')) doSomething();
Since myObj doesn't have any property text, the doSomething() function will never be called.
This is the behaviour of JavaScript as mentioned by many/all answers. However there is an option to prevent new properties you might want to try:
Object.seal https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/seal
The simple answer is JavaScript is not ment to be typesafe...You shouldn't check it, but if you still want to check you can do it by:
if ('len' in mystring){
}
You should look into Typescript if you ask this question...
Until today, I had not known the with operator existed. I stumbled upon it while debugging an issue being thrown from a plugin (Backbone.Epoxy).
The operator creates block level scope for each property on the passed object.
var testObj = { "cat":true };
with (testObj) {
console.log(cat ? "Cat!": "dog"); // Cat!
}
Simple enough? Initially I thought this could potentially be really cool. Until I realized why my code was throwing an error. Here is an example derived from my code.
var testObj = { "css":true, "background-color":"blue" };
with (testObj) {
console.log(css ? background-color : ""); // throws
}
The actual code is a bit more dynamic, but this is essentially what occurs behind the scenes in the plugin. Since dashes are not allowed within variable names but are allowed in property names, which cause the error to be thrown.
So, to the questions:
Is there a way to sanitize the block scope local variable in order to avoid the issues with the dash while keeping it in my property name?
Has anyone else worked around this issue with epoxy?
You would have to make an exception and write:
testObj["background-color"]
As you may suspect, you cannot write just background-color, for the same reason you cannot write testObj.background-color. You should also ask whether using with, which is fairly non-standard, is worth the character-count savings. Usually the answer is "no".
As I know, in JavaScript there is no good solution to make private member. Solution described here is not efficient, because private members become parts of objects, not prototypes, and hence require more memory.
So, I decided just use Python practice - to mark private stuff with leading underscore, letting other to know that makred property or method is not intended to be used from outside.
But there is well-known code quality tool - JSLint, and it suggests to not use leading or trailing underscores.
What is the rationale behind this? Is this just code style suggestion or underscores can lead to more serious problems? If its just code style convention in JS community, how strong it is?
JSLint is a good tool, but it expresses opinions about coding practices that are in the style of its authors. Read about what those preferences are here. There is no harm in the JavaScript parser in using a leading underscore/underbar, the tool is programmed to see this as a bad convention and warn you against using it. If using leading underscores is your preference and it makes sense, use them.
If you don't want to see the warnings in JSLint when using identifiers that begin with an underscore/underbar there is a setting within JSLint to hide these from you. Wrap the code that you don't want to be evaluated like this example and you won't see the warnings:
/*jslint nomen: true */
var _gaq = {};
/*jslint nomen: false */
This is true if you're having code evaluated from a file, but if you're on the JSLint website there is an option to "Tolerate... dangling _ in identifiers" that removes the warning as well.
Please note that doing this may cause issues in how JSHint parses the file. Take a look at this link showing JSLint vs JSHint in relation to that flag. But if you're going to go by the JSLint standard mixing JSHint can cause a bit of confusion.
Private variables don't exist in JavaScript without using closures, but it's not a pattern needed for every project execution. If you want to know more about closures in JavaScript check out Ben Nadel's wonderful blog post and NetTuts+
It's just a code style suggestion.
You can use JSHint instead and set-up it following the code style in your project/company.
As to me there's nothing bad if you mark private members in this way. The main rule should be to follow the unified convention in the whole project. If this makes your code more readable and maintainable, you're free to follow own convention for current project.
Underscore prefix can be use as convention. But is just a convention.
If the private member is a property of the object's instance the only way is to declare a variable in constructor. The properties of an object are never registred in prototype. If you store a property in proto, his value was share with all other instance.
It work like statics in POO.
The prototype is only use to solve an undefined property in the instance.
Exemple:
function O(){}
O.prototype.name = "John";
var o = new O;
// o look like that :
// {
// __proto__: { name: "John"}
// }
console.log(o.name); // write "John"
o.name = "Tom";
// now :
// {
// name: "Tom",
// __poto__: { name: "John" }
// }
console.log(o.name); // write "Tom"
The definition of name on instance not override the prototype value. It only store in the instance before the proto value in cascade resolution.
Sorry for my bad english.