The Node binding ships prebuilt natives, so npm install does not drag node-gyp, Python and a C++ toolchain onto your build machines.
npm install @keynub/licdongleCode language: Bash (bash)const { Context } = require('@keynub/licdongle');
const ctx = new Context();
const dongle = ctx.open(); // first dongle found
dongle.verifyGenuine(); // throws unless genuine
const session = dongle.openSession();
const license = session.readRecord('license');
session.close();
dongle.close();
ctx.close();Code language: JavaScript (javascript)Electron: Check in the Main Process
Do the dongle work in the main process, not the renderer. A renderer is a browser context: its JavaScript is shipped as readable source inside your app bundle, and anyone can open devtools against it. Anything you decide in the renderer, the user can re-decide.
Better still, decrypt the data your application needs in the main process and pass the result over IPC, rather than passing a boolean the renderer is trusted to honour.
And the rule that matters in every language: do not branch on a boolean. Encrypt data your program needs with appEncrypt at build time and decrypt it through the dongle at run time, so removing the check leaves the program with nothing to compute rather than a working unlicensed copy.
Why an FFI Rather Than a Native Addon
The binding reaches the C core through koffi, an FFI. For an Electron dependency that is the difference between working and becoming a support burden: no node-gyp, no Python and no C++ compiler on every developer’s machine, and no rebuild for each Electron ABI. A native addon has to be recompiled for every Electron version you upgrade to. An FFI binding does not.
The trade is that the C signatures live in the binding as strings no compiler checks, so each one is held to the C prototype it mirrors.
Shipping the Native Library with a Node.js or Electron Application
The @keynub/licdongle package on npm carries the native library for every platform under prebuilds/<platform>-<arch>/ and calls it through an FFI (koffi), so there is no native addon to compile, no node-gyp, no rebuild per Node or Electron version. The binding looks in KEYNUB_LICDONGLE_LIBRARY, then prebuilds/, then beside the package, then next to the executable, then on the system search path.
For Electron, a shared library cannot be loaded from inside an asar archive: mark the package as unpacked (asarUnpack in electron-builder, or the equivalent in Forge) and keep the dongle calls in the main process. On Linux, install the udev rule from NATIVES.md once, so that ordinary users may open the device.
Questions Node.js Developers Ask
Which Node.js Versions Does the Binding Support?
Node.js 18 and later, and the Electron releases built on them, on Windows, Linux and macOS.
Does an Electron App Need a Native Module Rebuild for the Dongle?
No. The binding calls the native library through an FFI rather than a compiled addon, so an Electron version change needs no electron-rebuild. Only the asar rule above applies.
Does a Node.js Application Need Administrator Rights to Talk to the Dongle?
No, and no driver either: the dongle is a USB HID device that the operating systems handle with their built-in class drivers. On Linux, install the shipped udev rule once so that ordinary users may open it; without the rule the SDK reports access denied and names the cause in its error detail.
Does a Node.js License Check Need an Internet Connection?
No. Verification is a local exchange between your program and the dongle over USB: the SDK checks the dongle’s certificate chain to KeyNub’s root and runs a live challenge-response. There is no activation server and no account, so the check works on air-gapped machines.
Who Can Read the License Records on a Dongle?
Anyone holding the dongle: a program opens a session and reads records, and can decrypt data sealed for that dongle. Writing records, erasing them and incrementing counters need your write key. What the dongle guarantees is that none of it is available without the dongle present.
Can a License Written from Node.js Be Read by a Program in Another Language?
Yes. Every binding drives the same core library and the same dongle, and records and sealed data are language-neutral bytes. Your issuing tool can be written in one language and your product in another.
Code
Runnable sample: nodejs/verify_and_read.js. Binding source: bindings/nodejs. Both are Apache-2.0, in the public SDK repository; the prebuilt native libraries are in the repository’s natives/ folder, one per platform.
All supported languages · All industries · Buy a KeyNub · Ask us something
