Ignition Parent Project IP Is Protected Only by Stripping It

Why did importing the parent into a new project expose everything?

Start with the data path. A vendor's Designer connects to a gateway, the gateway reads the project resources from its own store, and the gateway decides what that session may open or change. Two protections were applied to this parent project: a required designer role and blocked overrides. Both are checks run by the gateway that hosts the project, against that gateway's own user source and that project's inheritance settings.

An exported project is a set of resource files. The protections do not travel with those files as enforcement. They travel as settings, and the administrator of the receiving gateway decides whether to honor them. When the vendor created a new project and imported both the parent and the child into it, three things happened:

• The parent resources became local resources of a new project the vendor owns. That project has no inheritance relationship with anything, so there is no override for the gateway to block.
• The role requirement is checked against a user source the vendor administers. The vendor can give themselves any role.
• The resource content, including templates and scripts, was never encrypted. It opens like any other local resource.

Designer role requirements are guard rails. They are not access control against the person who runs the gateway. Anyone with designer access to a gateway can also run arbitrary code in gateway scope. Ignition does not offer a control that keeps a shipped resource unreadable or uneditable on a gateway you do not administer.

Check 1: Which gateway does the vendor's Designer connect to?

Take the reading from the Designer launcher's gateway address and from the answer to one question: who holds the gateway admin credentials?

• Vendor's own gateway: every project-level protection is void. Treat every resource you ship as disclosed and editable. Go to Check 2.
• A development gateway you host: project security is still bypassable through gateway-scope code, but you control what exists on that server. Go to Check 4, then return to Check 2 for the resource list.

Check 2: Which parent resources does the child actually reference?

Inventory the parent by what the child needs to open, render, and run. Anything the child instantiates or calls must exist on the vendor's gateway in some form. Anything it never touches has no reason to leave your building.

Outcome: whatever must ship intact is disclosed, and protection for it rests on the NDA. Whatever can be stubbed or removed is protected by absence. Go to Check 3.

Check 3: Can vendor edits to their parent copy reach your system?

At integration you use your master copy of the parent. A vendor who edits their copy only changes their own gateway. Those edits reach production through one path only: the child project export you import. That narrows the change-control problem to one artifact.

Take the reading from the resource tree of the child export, both in the Designer project browser on a scratch gateway and in the export file listing:

• Only child-owned resource paths: proceed to the procedure.
• Resource paths that duplicate parent paths: these are overrides. Once the child inherits from your master parent, they shadow your templates or scripts. Delete them or reject the delivery.
• Copies of parent templates renamed inside the child: these do not break the parent. They do fork your standard. Reject them if the contract requires use of the provided templates.
• Gateway event scripts or timer scripts in the child: these run in gateway scope on your server after import. Review every line before import.

The acceptance test is functional: the child must run correctly against your unmodified master parent.

Check 4: If you host the dev gateway, what can the vendor reach?

Granting designer access grants total practical control of that gateway, including arbitrary gateway-scope code. Size the hosted gateway so that total control costs you nothing.

A hosted gateway gives you visibility into the work. It does not keep resources secret from the designer. The resource-stripping procedure applies either way.

How do you build the vendor release and verify integration?

1. Create a new project on your gateway from a copy of the master parent. Name it as a vendor release so it cannot be confused with the master.
2. Delete every resource from the Check 2 inventory marked "Not shipped" or "Removed".
3. Replace each called script function with a stub that keeps the script path, function name, argument list, and return structure. Document expected behavior in the stub's docstring instead of in code.
4. Create the child project inheriting from the vendor release parent, and verify it opens and runs with no missing-resource errors.
5. Export the vendor release parent and the child. Open the parent export on a scratch gateway and confirm no proprietary resource is present.
6. Deliver both exports with the resource-path rules in writing: no overrides of parent paths, no gateway-scope scripts without approval.
7. On delivery, import the returned child onto a scratch gateway first. Walk the resource tree per Check 3 and remove any overrides.
8. Import only the child onto your integration gateway and set its parent to your master parent. Never import a parent project from a vendor.

Verification:

1. In the Designer on your gateway, open the child and confirm every inherited template and script shows as inherited from the master parent, with no local override.
2. Compare the master parent's resources against your last known-good export. No resource should have changed.
3. Open a second, unrelated child project that uses the same master parent and confirm it still runs unchanged.
4. Run the vendor's child through its functional test against the master parent. Payment is released when it passes with the real script bodies in place of the stubs.

FAQ