⛵ Land & Catch Test Site

How the Identity Browser Extension Land & Catch work

Three things being tested

Most toggles on this site target Catch. randomids is deliberately a Land only failure (Catch still succeeds the first time). pwchange, the baseline card's Sign Up tab, and noautocomplete target the password generator.

isRootDoc

Internal diagnostic logs show a LandCatchMonitor component explicitly checking isRootDoc before offering to catch an app. If the login form's POST happens inside a child iframe rather than the top level document, this check fails and Land & Catch does not fire. This is the confirmed mechanism behind the iframe toggle.

CAPTCHA and iFrame are both officially unsupported

Idira's published application requirements state: "The browser extension does not support Captcha, embedded web applications such as iFrame, Flash, Shockwave, Java, or Visual Basic." The iframe toggle's mechanism is confirmed via the isRootDoc log evidence above; no equivalent internal detail explains how CAPTCHA is detected, so the captcha toggle is a documented outcome without a confirmed mechanism. It uses a real hCaptcha widget (not a fake lookalike) since detection is likely signature based, and a fake widget wouldn't match any real CAPTCHA vendor's markup.

Other gates before Catch fires

The same logs show three additional checks: user can create app, policy enabled, and a per site skip list (local enabled, cleared via the extension's "Clear Skipped Sites" button). These are account or policy level and can't be simulated from a static test page, but if Land & Catch never fires on any site for a given tester, check these first before assuming a page shape issue.

Field matching by CSS selector

Captured apps are replayed using CSS selectors, often keyed off an input's id attribute (e.g. input#UserName). If a site regenerates that id on every page load, initial Catch still succeeds, but replay ("Land") on the next visit fails because the saved selector no longer matches anything. This is what the randomids toggle reproduces.

Order script primitives

Advanced or manually configured apps can script a login sequence using primitives like fill, click, sleep, waitForNewPage, and submit, for example [["fill","username"],["click","#next"],["sleep",2000],["fill","password"],["submit"]]. This is how support handles sites with a "Next" button reveal, a mandatory 3rd field, or an iframe scoped login (using an ["iframe",{"whitelist":...,"blacklist":...}] command), but it requires a human to manually configure it. The spareveal, extrafield, and iframe toggles all model cases the basic and generic automatic template (what Land & Catch itself uses) isn't built to handle without this kind of manual scripting.

Sourced from an internal Idira training document ("IBE Setup & Troubleshooting", Module 506) and docs.cyberark.com's Browser Extension application requirements & restrictions page (Idira's documentation still lives under the legacy CyberArk domain at time of writing).