Friday, September 13, 2019

iOS UNUserNotifications Learning



The trigger is the main this. We can either use TimeInterval or Calendar Trigger.
For repeating intervals, 60 seconds or more must be the minimum between two repeating ones.
Does it actually apply for non repeating? For e.g. If we set 5 different alarms separately
With 5 different identifiers, do they fire? To be checked!

From the investigations by doing sample, the info that I could collect is that we are not able to
Get the notification even if not repeat is set to true and even if the identifier is set as unique one,
It just posts for 2 and then it stops posting!. Not sure if it is something specific to testing


OK with a bit of investigation, the crux is around the type of trigger. The time interval trigger could be used
For repeating ones.

Below setup works well to repeat the notification every X times

let content = UNMutableNotificationContent()
        content.title = "Pizza Time!!"
        content.body = "Monday is Pizza Day"

var timeInterval : TimeInterval = 60;

let trigger = UNTimeIntervalNotificationTrigger(
            timeInterval: timeInterval,
            repeats: true)
        content.title = "Pizza Time!! "
        let request = UNNotificationRequest(identifier: baseID, content: content, trigger: trigger)
       
        UNUserNotificationCenter.current().add(request) { (error) in
            if let error = error {
                print("error in pizza reminder: \(error.localizedDescription)")
            }
        }


Now as per documentation, we should not have < 60 seconds for a repeating one.

This works best if schedule every X second using scheduler interval than calendar date.


References:
https://makeapppie.com/2017/01/31/how-to-repeat-local-notifications/

CWE, and CERT Secure Coding Standards



Common Weakness Enumeration

The Common Weakness Enumeration (CWE) is a unified, measurable set of software weaknesses that enables the effective discussion, description, selection, and use of software security tools and services that can find these weaknesses in source code and operational systems. The CWE also enables better understanding and management of software weaknesses related to architecture and design. It enumerates design and architectural weaknesses, as well as low-level coding and design errors.

CERT Secure Coding Standards

CERT is developing secure coding standards for commonly used programming languages such as C, C++, and Java through a broad-based community effort that includes members of the software development and software security communities. Well-documented and enforceable coding standards are essential to secure software development. Coding standards encourage programmers to follow a uniform set of rules and guidelines determined by the requirements of the project and organization, rather than by the programmer’s familiarity or preference. Once established, these standards can be used as a metric to evaluate source code (using manual or automated processes) to determine compliance with the standard.

CERT secure coding standards include guidelines for avoiding coding and implementation errors, as well as low-level design errors.

CERT-CWE Relationship
The CWE and the CERT secure coding standards perform separate but mutually supportive roles. Simply stated, the CWE provides a comprehensive repository of known weaknesses, while CERT secure coding standards identify insecure coding constructs that, if present in code, could expose a weakness or vulnerability in the software. Not all weaknesses enumerated in the CWE are present in any particular secure coding standard because not all weaknesses are present in each language and because the CWE also includes high-level design issues. Not all CERT secure coding guidelines are mapped directly to weaknesses in the CWE because some coding errors can manifest in ways that do not directly correlate to any given weakness. Both tools are necessary in evaluating the security and safety of software systems.


References:
https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=50399
https://www.us-cert.gov/bsi/articles/knowledge/coding-practices/mitre-cwe-and-cert-secure-coding-standards

Node JS - C++ Add On with file reading



Basic C++ code to read the text file is below

#include
using namespace std;

ifstream inFile;

inFile.open("C:\\temp\\datafile.txt");

if (!inFile) {
    cerr << "Unable to open file datafile.txt";
    exit(1);   // call system to stop
}

while (inFile >> x) {
  sum = sum + x;
}

inFile.close();


Now the above can be converted to node module like the below. The same worked without issues


#include "functionexample.h"
#include
#include
using namespace std;
std::string functionexample::hello(){
    return "Hello World";
}
Napi::String functionexample::HelloWrapped(const Napi::CallbackInfo& info)
{
    Napi::Env env = info.Env();
    Napi::String returnValue = Napi::String::New(env, functionexample::hello());
    ifstream inFile;
    inFile.open("test.txt");
    if (!inFile) {
        cout << "Unable to open file";
//        exit(1); // terminate with error
    }
    else {
        cout << "Opened the file";
    }
    return returnValue;
}
Napi::Object functionexample::Init(Napi::Env env, Napi::Object exports)
{
    exports.Set("hello", Napi::Function::New(env, functionexample::HelloWrapped));
    return exports;
}




References:
http://www.fredosaurus.com/notes-cpp/io/readtextfile.html

What is Web Fingerprinting?



Web Finger printing is something that lets us to uniquely identify a browser execution which in case if to be done on an non logged in environment.

Usual sources for web finger printing are


    User Agent
    HTTP_ACCEPT Headers
    GEO-ip

There is an express middleware which is helping to implement the finger printing and it is like below

var Fingerprint = require('express-fingerprint')

app.use(Fingerprint({
    parameters:[
        // Defaults
        Fingerprint.useragent,
        Fingerprint.acceptHeaders,
        Fingerprint.geoip,

        // Additional parameters
        function(next) {
            // ...do something...
            next(null,{
            'param1':'value1'
            })
        },
        function(next) {
            // ...do something...
            next(null,{
            'param2':'value2'
            })
        },
    ]
}))

app.get('*',function(req,res,next) {
    // Fingerprint object
    console.log(req.fingerprint)
})


References:
https://www.npmjs.com/package/express-fingerprint

Thursday, September 12, 2019

Procedure for creating Node JS add ons

Below is how to setup the boiler plate code

mkdir test-addon
cd test-addon
git init
npm init

Now install the dependencies

npm install node-gyp --save-dev
npm install node-addon-api

node-gyp is the toolchain to compile the addons.
node-addon-api is a helper project as described earlier that will make writing C++ addons easier.


Couple of files that are important during the process are:

1. Bindings.gyp
2. package.json

Below is a sample content for this

Binding.gyp

{
    "targets": [{
        "target_name": "testaddon",
        "cflags!": [ "-fno-exceptions" ],
        "cflags_cc!": [ "-fno-exceptions" ],
        "sources": [
            "cppsrc/main.cpp"
        ],
        'include_dirs': [
            "<!@(node -p \"require('node-addon-api').include\")"
        ],
        'libraries': [],
        'dependencies': [
            "<!(node -p \"require('node-addon-api').gyp\")"
        ],
        'defines': [ 'NAPI_DISABLE_CPP_EXCEPTIONS' ]
    }]
}

package.json

{
  "name": "test-addon",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "gypfile": true,
  "scripts": {
    "build": "node-gyp rebuild",
    "clean": "node-gyp clean"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "node-gyp": "^3.7.0"
  },
  "dependencies": {
    "node-addon-api": "^1.3.0"
  }
}


Just to note, gypfile:true should be present here

Now having these files set up, compilation of the modules can be done in the below steps

npm run build

This will generate the testaddon.node file in the release folder


The add on can be used like this below

const testAddon = require('./build/Release/testaddon.node');
console.log('addon',testAddon);
module.exports = testAddon;


binding.gyp file contains all the files that need to be compiled and all the include files / libraries that the project will be using. If you notice we have added cppsrc/main.cpp file as our source file.


References:
https://medium.com/@atulanand94/beginners-guide-to-writing-nodejs-addons-using-c-and-n-api-node-addon-api-9b3b718a9a7f

C++ Node files Looking into details and adding a method

Below is some description of main.cpp file

1. #include includes the napi header file so that we can access all the helper macros, classes and functions.
2. NODE_API_MODULE is a macro that accepts modulename and registerfunction as parameters.
3. In our case registerfunction is InitAll and it takes two parameters which are passed by N-API. First parameter env is the context that needs to be passed on to most N-API function and exports is the object used to set the exported functions and classes via N-API.


/**
* This code defines the entry-point for the Node addon, it tells Node where to go
* once the library has been loaded into active memory. The first argument must
* match the "target" in our *binding.gyp*. Using NODE_GYP_MODULE_NAME ensures
* that the argument will be correct, as long as the module is built with
* node-gyp (which is the usual way of building modules). The second argument
* points to the function to invoke. The function must not be namespaced.
*/
NODE_API_MODULE(NODE_GYP_MODULE_NAME, Init)


Now to add a method to the C++ function using N-API

std::string hello(){
  return "Hello World";
}

To export this to javascript side, we have to do quite lot of work!

We need to have a header file and a cpp file containing implementations

Below given is hellosample.h

#include
namespace hellosample {
  std::string hello();
  Napi::String HelloWrapped(const Napi::CallbackInfo& info);
  Napi::Object Init(Napi::Env env, Napi::Object exports);
}


#include "hellosample.h"
std::string hellosample::hello(){
  return "Hello World";
}
Napi::String hellosample::HelloWrapped(const Napi::CallbackInfo& info)
{
  Napi::Env env = info.Env();
  Napi::String returnValue = Napi::String::New(env, hellosample::hello());

  return returnValue;
}
Napi::Object hellosample::Init(Napi::Env env, Napi::Object exports)
{
  exports.Set(
"hello", Napi::Function::New(env, hellosample::HelloWrapped)
  );

  return exports;
}


For every function in C++ we want to export we will basically create a NAPI wrapped function (HelloWrapped in this example) and add it to the exports object using Init.
Every wrapped function that needs to be exported to JS should have input params/return value from the Napi namespace.

Every wrapped function takes in CallbackInfo as the input parameter. This contains things like the context and the input parameters that needs to be passed to the function.
Initfunction is used to just set the export key as hello with corresponding wrapped function HelloWrapped .


OK, having defined these extra files, we need to tell the node gyp that we have added these files.This includes making changes to the binding.gyp, main.cpp, index.js files
Below is how to do that


In the gyp file, in the sources array, add the new file that is to be compiled. The new gyp file will be like this below

"sources": [
-            "cppsrc/main.cpp"
+            "cppsrc/main.cpp",
+            "cppsrc/Samples/functionexample.cpp"
         ],


main.cpp will be like this below

 #include
+#include "Samples/functionexample.h"

 Napi::Object InitAll(Napi::Env env, Napi::Object exports) {
-  return exports;
+  return functionexample::Init(env, exports);
 }

index.js can be like below

 const testAddon = require('./build/Release/testaddon.node');
 console.log('addon',testAddon);
+console.log(testAddon.hello());
 module.exports = testAddon;


References:
https://medium.com/@atulanand94/beginners-guide-to-writing-nodejs-addons-using-c-and-n-api-node-addon-api-9b3b718a9a7f

What is Node JS add-on?


Node.js Addons are dynamically-linked shared objects, written in C++, that can be loaded into Node.js using the require() function, and used just as if they were an ordinary Node.js module. They are used primarily to provide an interface between JavaScript running in Node.js and C/C++ libraries.

There can be many reasons to write nodejs addons:
1. You may want to access some native apis that is difficult using JS alone.
2. You may want to integrate a third party library written in C/C++ and use it directly in NodeJs.
3. You may want to rewrite some of the modules in C++ for performance reasons.


References:
https://medium.com/@atulanand94/beginners-guide-to-writing-nodejs-addons-using-c-and-n-api-node-addon-api-9b3b718a9a7f

What is N-API?

N-API (pronounced N as in the letter, followed by API) is an API for building native Addons. It is independent from the underlying JavaScript runtime (ex V8) and is maintained as part of Node.js itself. This API will be Application Binary Interface (ABI) stable across versions of Node.js. It is intended to insulate Addons from changes in the underlying JavaScript engine and allow modules compiled for one version to run on later versions of Node.js without recompilation.

In essence , N-API can be used to build NodeJS Addons using C or C++. And the addons built using this would not break across different implementations or versions of NodeJS.
N-API is a stable API as of Node v10 (latest stable release when writing this article). N-API was experimental in Node v8 and v9.

References:
https://medium.com/@atulanand94/beginners-guide-to-writing-nodejs-addons-using-c-and-n-api-node-addon-api-9b3b718a9a7f

CORS is enabled but still some requests are failing with CORS error

The issue was because some of the additional headers added when making the request.
When the server is configured to have below as allowed headers, anything else will
Likely get into the CORS issue again.


References:
https://stackoverflow.com/questions/7067966/why-doesnt-adding-cors-headers-to-an-options-route-allow-browsers-to-access-my

What is NW.js

NW.js is a framework for building desktop applications with HTML, CSS, and JavaScript. It was created by Roger Wang at Intel’s Open Source Technology Center in China, and worked by combining the Node.js programming framework with Chromium’s (then) browser engine - Webkit, hence the original name Node Webkit.

By combining Node.js with Chromium, Roger found a way to create applications that could not only load a local web site within an application window, but also could interact with the Operating System via a JavaScript API. This JavaScript API could control visual aspects like window dimensions, toolbar and menu items, as well as provide access to local files on the desktop. These are things that can’t be done with a hosted web site, or even a locally hosted web site. Below is an example of how an example application works.


In the example illustrated above, the application’s files resemble those of a simple web site. The index.html web page is like most other web pages that you’ve seen - there is some HTML code for the page’s content, a link tag for the CSS stylesheet, and a script tag for the JavaScript. At this stage it’s identical to a website, and if you were to open it in a web browser it would work the same as it would in NW.js. There is also a CSS stylesheet for styling the contents of the index.html file, and an app.js file for executing JavaScript, in this case calling a simple dialog box with the text “from NW.js” inside of it.

You’ll also notice a package.json file as well. This is the manifest file used by Node.js to load applications and libraries, and NW.js uses it to store configuration information about the desktop application. It is required by NW.js for the application to load.

The NW.js application is able to load an application with a given path of the folder where the files live. It looks for the package.json file, which points to the index.html file to load, and thus loads the web page into what looks like a web browser embedded inside of an application window. This is what you can expect to see:

The example application above could load inside of a web browser without any modifications, but where NW.js differs from a web browser is that where an app.js file could only interact with the index.html’s contents in the context of a web browser, NW.js allows the app.js file to interact with the Operating System through a custom JavaScript API, as well as through Node.js. This is unlike web frameworks where the front-end code and the back-end code traditionally exist and execute in separate places. The idea of front-end and back-end code existing and executing in the same place is the key concept to grasp here.


Interacting with the Operating System

NW.js provides a JavaScript API for interacting with the Operating System, so that you can do the following:
Control the size and behavior of the application’s window
Display a native toolbar on the application window, with menu items
Add context menus in the application window area on right-click
Add a tray application item in the Operating System’s tray menu
Access the Operating System clipboard; read the contents and even set the contents as well
Open file, folders and URLs on the computer using their default applications
Insert notifications via the Operating System’s notification system.


References:
https://dzone.com/articles/what-is-nwjs?fromrel=true