DEV Community: Victory Osikwemhe

Policies in NodeJS - Part 1

Victory Osikwemhe — Sun, 27 Feb 2022 23:35:53 +0000

Policy is one of the less frequently talked about features in NodeJS. The purpose of this feature is to enforce a level of security to what kind of code is loadable into your NodeJS Application (Which is kind of similar to deno --allow-<module> but more multifaceted).

Policies are currently experimental and can be used with the --experimental-policy flag

This feature was introduced recently, and may change
or be removed in future versions. Please try it out and provide feedback. If it addresses a use-case that is important to you, tell the node core team.

Every loadable code will go through an integrity verification check by comparing the sha256 value (base64 encoded) with what was specified in relation to that resource as well as all subresources. If there is a mismatch of the sha256 value with what was specified in the policy manifest file (this file dictates how a code should or should not be loaded), the behavior of what happens next will be defined in the policy manifest file.

The sha256 value is calculated from the content of the loadable resource.

For example, if we have this code

console.log('test')

copy the above into an empty folder and name it test.js
To get the sha256 value of test.js, you can use the oneliner specified in the node documentation for policies

node -e 'process.stdout.write("sha256-");process.stdin.pipe(crypto.createHash("sha256").setEncoding("base64")).pipe(process.stdout)' < ./test.js

{
   "onerror": "log",
   "resources": {
      "./test.js": {
         "integrity": "sha256-LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ="
      }
   }
}

copy the above into the same folder as test.js and name it policy.json

onerror can either be log , throw, or exit. When the integrity check fails, log outputs the error and continues execution of your program.

The loadable resources in this context is test.js. When onerror is not specified the default value is throw, it logs out the error and does not continue executing your program.
Running the below command will output a bunch of ERR_MANIFEST_ASSERT_INTEGRITY as well as test.

node --experimental-policy=./policy.json ./test.js

not specifying the integrity field, defaults to null specifying true as the value for integrity bypasses the verification check. Any loadable resource that is loaded using either require or import is also subject to the integrity verification check. The sha256 value becomes invalid when a little change is made to any of the loadable resource

Change the onerror value from log to either throw or exit to see how it behaves when a wrong sha256 value is used for a resource

Enabling/Disabling modules from been loaded

copy the below code into test-2.js

const fs = require("node:fs");
const os = require("node:os");
const test2_1 = require("./test-2-1.js");
console.log(fs.statSync(__filename));
console.log(os.userInfo());

copy the below code into test-2-1.js

const net = require("node:net");
console.log(new net.SocketAddress());

Run the below oneliner to generate the sha256 value for integrity verification.

node -e 'process.stdout.write("sha256-");process.stdin.pipe(crypto.createHash("sha256").setEncoding("base64")).pipe(process.stdout)' < ./test-2.js

node -e 'process.stdout.write("sha256-");process.stdin.pipe(crypto.createHash("sha256").setEncoding("base64")).pipe(process.stdout)' < ./test-2-1.js

copy the below manifest into policy-2.json

{
  "onerror": "log",
  "resources": {
    "./test-2.js": {
      "integrity": "sha256-input test-2.js base64 encoded hash here",
      "dependencies": {
        "node:fs": true,
        "node:os": true,
        "./test-2-1.js": true
      }
    },
    "./test-2-1.js": {
      "integrity": "sha256-input test-2-1.js base64 encoded hash here",
      "dependencies": {
        "node:net": true
      }
    }
  }
}

The dependencies field contains the list of dependencies (used in a resource or subresource) and the rules of how it should be loaded. Subresource are resources that are loaded by other resource, for example test-2-1.js is a subresource to test-2.js

Run
node --experimental-policy=./policy-2.json ./test-2.js

The output will be something like this , depending on your computer

SocketAddress { address: '127.0.0.1', port: 0, family: 'ipv4', flowlabel: 0 }
Stats {
  dev: 16777221,
  mode: 33188,
  nlink: 1,
  uid: 502,
  gid: 20,
  rdev: 0,
  blksize: 4096,
  ino: 15164992,
  size: 170,
  blocks: 8,
  atimeMs: 1645483771373.328,
  mtimeMs: 1645483770300.6633,
  ctimeMs: 1645483770300.6633,
  birthtimeMs: 1645482935166.657,
  atime: 2022-02-21T22:49:31.373Z,
  mtime: 2022-02-21T22:49:30.301Z,
  ctime: 2022-02-21T22:49:30.301Z,
  birthtime: 2022-02-21T22:35:35.167Z
}
{
  uid: 502,
  gid: 20,
  username: 'victoryosikwemhe',
  homedir: '/Users/victoryosikwemhe',
  shell: '/usr/local/bin/bash'
}

policy-two.json manifest file enables every dependency required/imported in ./test-2-1.js and ./test-2.js, a dependency can be disabled by setting the value of the dependency to false

{
  "onerror": "log",
  "resources": {
    "./test-2.js": {
      "integrity": "sha256-input test-2.js base64 encoded hash here",
      "dependencies": {
        "node:fs": true,
        "node:os": true,
        "./test-2-1.js": true
      }
    },
    "./test-2-1.js": {
      "integrity": "sha256-input test-2-1.js base64 encoded hash here",
      "dependencies": {
        "node:net": false
      }
    }
  }
}

setting node:net to false disables the node core net module in only test-2-1.js , when test-1.js tries loading test-2-1.js it will cause an error.

Run
node --experimental-policy=./policy-2.json ./test-2.js

It will throw ERR_MANIFEST_INVALID_RESOURCE_FIELD(href, 'dependencies') on test-2-1.js

Enforcing using `import`

You can also enforce that a module should be loaded with import or require

Modify test-2.js and test-2-1.js respectively to look like the below (You will have to generate the sha256 value of the contents)

test-2.js

const { syncBuiltinESMExports } = require("node:module");
const os = require("node:os");
const test2_1 = require("./test-2-1.js");

console.log(os.userInfo());

syncBuiltinESMExports();

import("node:fs").then( f => {
  console.log(f.statSync(__filename));
});

test-2-1.js

const net = require("node:net");
console.log(new net.SocketAddress());
module.exports = {};

(Note: Generate a new sha254 value for the above resources, you can also set integrity to true to avoid doing this for every little change - even for a single space)

{
  "onerror": "log",
  "resources": {
    "./test-2.js": {
      "integrity": true,
      "dependencies": {
        "node:fs": { "require": true },
        "node:os": { "import":  true },
        "node:module": true
        "./test-2-1.js": true
      }
    },
    "./test-2-1.js": {
      "integrity": true,
      "dependencies": {
        "node:net": true
      }
    }
  }
}

Run
node --experimental-policy=./policy-2.json ./test-2.js

This will throw ERR_INVALID_URL because ./test-2.js should only load node:fs with esm import. Changing require: true to import: true or loading node:fs with cjs require will make this check go away.

Sadly, switching the flip to module.createRequire behaves differently.

Loading a different module other than what is required/imported

Another form of dependency redirection is loading Module A when Module B was initially required/imported.

test-3.js

const fs = require('node:fs');
console.log(nodeFetch);
fs.readFileSync(__filename);

mocked-fs.js

module.exports = {
  readFileSync(location) {
    console.log({ location });
  }
}

policy-3.json

{
  "onerror": "log",
  "resources": {
    "./package.json": {
      "integrity": true
    },
    "./test-3.js": {
      "integrity": true,
      "dependencies": {
        "node:fs": "./mocked-fs.js"
      }
    },
    "./mocked-fs.js": {
      "integrity": true
    }
  }
}

Run
node --experimental-policy=./policy-3.json ./test-3.js

Output

{ location: '/Users/victoryosikwemhe/pp/test-3.js' }`

Instead of loading the fs module , it redirects to mocked-fs.js

The policy manifest file also supports scopes , import maps and cascading. I will cover them in the next part, until then, you can checkout the documentation on policies

$jsonSchema operator in mongodb

Victory Osikwemhe — Wed, 09 Sep 2020 17:35:12 +0000

Prior to MongoDB 3.6, there was no way to define what value(s) a field in a MongoDB document will be (even if we love it's schema-less nature, we might still have that feeling to be able to do something like this), we resolved into using an ODM like mongoose to be able to define a schema for a collection.

From MongoDB 3.6 it became possible to define a schema for a collection, but it's not as concise and 100% intuitive with the Mongoose approach.

The $jsonSchema is an evaluation operator in MongoDB, that does not only allow one define a schema for a collection, the $jsonSchema operator can also be used to match document(s) that meets a specific structure.

To be able to define a schema for a collection one has to use the db.createCollection method

db.createCollection("student", {
  validator: {
    $jsonSchema: {
      required: [
        "email",
        "phoneNumber",
        "fullName",
        "dateOfBirth",
        "subjects",
        "address",
      ],
      bsonType: "object",
      properties: {
        email: {
          bsonType: "string",
          description: "Email Address of student",
        },
        phoneNumber: {
          bsonType: "string",
          description: "Phone Number of the student",
        },
        fullName: {
          bsonType: "string",
          description: "student full name",
        },
        dateOfBirth: {
          bsonType: "date",
          description: "Date of Birth of student",
        },
        subjects: {
          enum: ["English", "Mathematics", "Biology", "Government"],
          description: "Value specified does not match the required subject",
        },
        address: {
          bsonType: "object",
          required: ["city", "street"],
          properties: {
            city: {
              bsonType: "string",
              description: "City of the student",
            },
            street: {
              bsonType: "string",
              description: "Street of user",
            },
            houseNumber: {
              bsonType: "int",
              description: "House number of the student",
            },
          },
        },
      },
    },
  },
  validationLevel: "strict",
  validationAction: "error",
});

From the above code, you will see the use of bsonType, bsonType stands for binary json, it's like a superset of json, and it supports various data types such as 64bit integer and regular expression, more information about this here.

The use of bsonType in the above code, is to specify what datatype a field accept, for the dateOfBirth the accepted datatype is a date object.

Let's try to insert an empty document and see what happens.

db.student.insert({})

When you run the above, MongoDB will show you this beautiful error message

WriteResult({
    "nInserted" : 0,
    "writeError" : {
        "code" : 121,
        "errmsg" : "Document failed validation"
    }
})

Now this brings us to the next point, the required option, the required option is an array of fields that must be exist in the document to be inserted. The validator requires the email, phoneNumber, fullName, dateOfBirth , subjects and address fields to be available when inserting a new document.
In our above example, we tried inserting an empty document, hence we got back that error. Let's correct this

db.student.insert({
  email       : "test@example.com",
  phoneNumber : "+234111111",
  fullName    : "Victory Osikwemhe",
  dateOfBirth : new Date("08/08/1996"),
  subjects    : "Physics",
  address     : {
    city      : "Abuja",
    street    : "Ademola Adetokunbo Crescent, Wuse 2"
  }
});

Running the above operation in mongo cli, we will also be presented with the previous error, and it's as a result of the wrong value specified to the subjects key. This brings us to what enum does, enum specifies the only values that a particular field is allowed to have, in our $jsonSchema validation object, we have something like this enum: [ "English", "Mathematics", "Biology", "Government" ] for the subjects field, and it's clear that "Physics" is not among the list, let's correct it by changing "Physics" to a valid value.

db.student.insert({
  email       : "test@example.com",
  phoneNumber : "+234111111",
  fullName    : "Victory Osikwemhe",
  dateOfBirth : new Date("08/08/1996"),
  subjects    : "Government",
  address     : {
    city      : "Abuja",
    street    : "Ademola Adetokunbo Crescent, Wuse 2",
    houseNumber : NumberInt(22)
  }
});

Everything is fine now.

They are two options above that controls the behaviour of the $jsonSchema validator

{
  validationLevel: "strict",
  validationAction: "error"
}

$jsonSchema is also capable of validating update operations also.

The validationLevel option specifies how well will MongoDB play with insert and update operation(s). This option only supports three values strict , off and moderate.

off does not perform any form of validation on the document that is been inserted or updated

strict applies the validation rules on all insert and update operation, basically no invalid document will be allowed.

db.student.updateOne({ email: "test@example.com"}, { $set: { dateOfBirth: "08/08/1997" } });

Running the above code, the result will be a Document failed validation error, because we are trying to update a field that only supports a date object.

moderate applies the validation rules on all insert and existing valid document in the collection.

The validationAction option controls how MongoDB reports the invalid document, it supports two values error and warn.

The error value prevents the invalid document from been inserted in the collection, same applies to trying to update a document with an invalid field.

The warn value logs out the error, but still allows the invalid document to be inserted/updated.

The $jsonSchema validator also have support for many keywords to further specify how a field should be validated.

$jsonSchema Keywords

The part 2 of this post will be on how to use $jsonSchema in query conditions to match documents that meets the specified criteria.

Thanks for reading :)

Understand the difference between isNaN and Number.isNaN

Victory Osikwemhe — Thu, 18 Jun 2020 07:54:43 +0000

Before we take a dive into the difference between isNaN and Number.isNaN, let's take a look at what NaN is

According to the javascript spec NaN stands for Not a Number, when you encounter something like this in javascript, you will have to cross check what you are trying to do it's either

you are trying to carry out an invalid mathematical operation or
you are trying to cast something that's not a number (except for a string of numbers) to a number for example

parseInt('hello'); // a string of characters cannot be converted to a number therefore the operation will return NaN

Number(undefined); // NaN

'string'/2; // NaN

One thing you have to know is that you cannot compare NaN to NaN or Number.NaN, therefore

parseInt('hello world') === parseInt('hello world'); // false

So you know, this does not have to do with strict equality comparison or abstract equality comparison

parseInt('foo') == parseInt('foo'); // false

But you can actually make a check for the above with Object.is

Object.is(parseInt('foo'), parseInt('foo')); // true
Object.is(NaN, NaN); // true

Apart from using Object.is , you can also check if a value is NaN, which can be done with

isNaN // on the global object
Number.isNaN

Which ever one you choose will determine how you will get backstabbed by javascript.
So this bring us to the difference between isNaN and Number.isNaN

isNaN does two things

It checks if the value passed to it is NaN or
It will try to coerce the passed value into a number if the result is NaN then the return value will be true

Number.isNaN does only one thing

It checks if the current value passed in actually NaN

for example

isNaN('javascript'); // true
The reason for this is because isNaN coerces 'javascript' to a number and since javascript is not a number the return value is false

Number.isNaN('javascript'); // false
The reason for this is because 'javascript' is a string and not the value NaN, so the return value will be false

isNaN(NaN); // true
NaN is not a number hence true

Number.isNaN(NaN); // true
NaN is not a number hence true

What you should get from the above is that Number.isNaN does not do any form of coercion, it just check if the value passed to it is NaN, if it's not NaN then the return value will be false.

Open to corrections, this is my first ever article. Thanks for reading

DEV Community: Victory Osikwemhe

Policies in NodeJS - Part 1

Enabling/Disabling modules from been loaded

Enforcing using import

Loading a different module other than what is required/imported

$jsonSchema operator in mongodb

Understand the difference between isNaN and Number.isNaN

Enforcing using `import`