How Clone Protection Prevents a Copy from Hijacking the Original Site

Clone protection prevents a copied QCTNH database from automatically redirecting the original installation’s service registration to a different hostname or path.

The clone scenario

  1. Production is registered with an installation UUID, service secret, origin, and native Joomla WebCron endpoint.
  2. A backup is restored to staging, carrying those same local values.
  3. The staging request origin no longer matches the registered production origin.
  4. Automatic QCTNH activity detects the difference and refuses to rotate identity or overwrite the service registration.

Evidence

Recent Activity can contain origin_mismatch_ignored. The Dashboard may show a Site Origin Mismatch warning and instruct the administrator to use Test Connection only if the move is intentional.

What explicit confirmation does

If staging genuinely needs its own service identity, Test Connection on that canonical staging URL rotates UUID/secret and registers it separately. Production keeps its own identity instead of being silently hijacked.

Use Recent Activity as migration evidence

For How Clone Protection Prevents a Copy from Hijacking the Original Site, QCTNH records useful origin lifecycle events. An unconfirmed different origin can produce origin_mismatch_ignored; an explicit accepted move can produce origin_changed_confirmed, followed by registration/synchronization results.

These events are safer evidence than guessing from a stale Connected badge after a restore or clone.

Community Discussion

Want to compare scheduler workflows, share practical tips, or discuss how you use this QCTNH feature? Visit the QC Task Nudge & Health Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.