Troubleshoot QCDR Discovery Sessions and Impact Scans

Most Discovery failures fall into a few distinct groups: plan or ACL authorization, an expired private session, an unsafe/unsupported URL, missing source evidence, or an Impact Scan fetch that could not obtain usable HTML.

Troubleshoot the exact stage that failed instead of repeatedly opening new inspectors or treating a LIKELY result as an EXACT match.

If Discovery Cannot Be Started

• Confirm QCDR Effective Tier provides Max-level Discovery access.
• Confirm the account can manage QCDR and has Run Discovery permission. A Super User is authorized automatically.
• Reload the Discovery tab after changing entitlement or ACLs so QCDR can issue a fresh private authorization.

If the launch button remains unavailable, resolve the plan/permission problem first. Do not try to copy an authorization value from another user or session; the token is signed and user-bound.

If the Inspector Says Discovery Is Not Authorized

Discovery authorization expires after 15 minutes. An invalid signature, expired token, blocked/deleted user, or lost Discovery permission fails closed. Return to Components > QC Dynamic Replacer > Discovery and start a new private session.

The error page intentionally does not activate the inspector. It remains private/no-store/noindex so a failed diagnostic URL does not become a public cached page.

If a Frontend URL Is Rejected

Use a normal frontend HTTP(S) URL on the same Joomla site. Real /administrator paths and external origins are not valid Discovery targets. Site Impact Scan additionally rejects obvious destructive routes and query parameters associated with logout, delete, remove, destroy, token, or similar action-style requests.

If your site uses a normal www/non-www variation, QCDR can normalize the same host when protocol and port still match. A genuinely different host is not treated as the same site.

If Explain This Output Finds Weak or No Stored Evidence

That does not mean the visible output is imaginary. It may be produced by PHP at runtime, assembled by a template/extension in a way that does not map cleanly to stored text, or changed later by JavaScript. Review render-boundary evidence and use Dynamic DOM Watch when timing suggests browser-side mutation.

Respect the confidence label. HIGH/MEDIUM/LOW candidates are correlations; only evidence QCDR marks PROVEN should be described as proven by Discovery.

If Site Impact Scan Reports an Error

Read the per-page error. QCDR can reject or fail a page because it:

• redirected outside the allowed frontend site;
• returned a failing HTTP status;
• returned a non-HTML response;
• took longer than the 12-second scan window;
• exceeded the 5 MB impact-scan response limit; or
• was cancelled by a newer scan.

Interpret EXACT, LIKELY, and NOT FOUND Correctly

EXACT means the fetched page contained the selected literal/visible value or an exact fingerprint. LIKELY means the best fingerprint scored at least 45% without becoming exact. NOT FOUND means that static fetched HTML did not provide strong enough evidence.

A page that builds the target only after browser JavaScript runs can legitimately appear NOT FOUND in the bounded fetch. Open that page in Discovery and use Dynamic DOM Watch before concluding the Rule has no impact there.

When to Start Over

Start a new Discovery session after authorization expiry, major navigation changes, or when the page you are investigating has materially changed. A new session gives you fresh request context; it does not erase saved Rules or modify existing Target Fingerprints.

Community Discussion

Want to compare workflows, share practical tips, or discuss how you use this QCDR feature? Visit the QC Dynamic Replacer Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.