Deployment Guide

1. Open the SecureJS console.
2. Choose JavaScript block, Complete HTML page, or Linked JS file mode.
3. Paste the matching source into the editor, or upload a .js, .mjs, .html, .htm, or .txt file.
4. Enter the author email used for ownership records.
5. Enter the authorised domain names where the protected script is allowed to run.
6. Enter a strong private key, or generate one with the key generator.
7. Obfuscate the script and deploy the generated output to the licensed site.

Choosing a Mode

• JavaScript block: use this for pasted JavaScript or a single inline script block.
• Complete HTML page: use this for a full page. Inline scripts are protected and linked script files are reported for separate protection.
• Linked JS file: use this for the contents of a .js file loaded through a script src tag.

When a file is uploaded, SecureJS displays its contents in the editor before protection so the author can review exactly what will be processed.

Module Imports

External module imports must stay readable so the browser can resolve them before the protected body runs. For example, imports from a CDN such as three.js are kept at the top of the module and the protected code receives the imported objects at runtime.

Module files that export values to other modules should normally be protected at the application entry point instead. Exports are synchronous module contracts, while hosted unlock is asynchronous.

Private Key Handling

Treat the author key as a production secret. It should belong to the original author only, should not be placed in public code, and should not be given to customers or end users. If the key is exposed, the author should rotate protection by generating a new protected build with a new key.

Common Pitfalls

• Weak keys: use a long random key. The generator is the preferred option for production builds.
• Wrong domain: the unlock request is domain checked. Add the exact hostnames that should be authorised.
• Invalid JavaScript: PHP templates, HTML markup, and server-side variables must be rendered before protection.
• Missing unlock endpoint: hosted unlock protection needs the SecureJS unlock service available at runtime.
• Lost key: SecureJS cannot recreate the author key if it was not saved by the author.

Frequently Asked Questions

Can someone reverse the generated file from source alone?

Not under the hosted-unlock design, assuming the author key and server-side payload store remain private. The generated file should not contain the key material required to decrypt the payload.

Can an authorised browser still be inspected?

Yes. Any browser that is authorised to run client-side JavaScript must receive executable code at some point. SecureJS raises the barrier and prevents static source-only reversal, but it cannot make executed browser code impossible to inspect.

What happens if the unlock service is unavailable?

The protected script cannot unlock until the service is available again. Production deployments should use monitored hosting, backups, and failover for the unlock endpoint.

Is my authorship watermark visible?

No. The watermark is embedded inside the protected payload metadata and is not shown as readable text in the deployed script source.

Should I reuse the same key?

For stronger isolation, use unique generated keys for important scripts or projects. Never share a private author key outside the author-controlled environment.