# ZopDay Hardens Auth Before Shipping Its IDP Install Link > Getting a teammate to install a specific app used to start with a conversation, not a click: open ZopDay, find Starter Templates, search the catalog, find the right chart, then start the flow. Every… Source: https://zop.dev/resources/blogs/shareable-install-link-zopday Published: 2026-08-12 · Author: riya-mittal · Tags: platformengineering, devops, selfservice --- Getting a teammate to install a specific app used to start with a conversation, not a click: open ZopDay, find [Starter Templates](https://zop.dev/resources/blogs/self-service-terraform-8-modules-60-percent-platform-tickets), search the catalog, find the right chart, then start the flow. Every step was a place someone could pick the [wrong thing](https://zop.dev/resources/blogs/why-your-ai-ops-agent-fixes-the-wrong-thing-first), or give up before finding it. A platform team recommending "just install WordPress from the catalog" was really asking someone to complete a four-step scavenger hunt correctly on the first try. That scavenger hunt is the same tax [platform teams](https://zop.dev/resources/blogs/the-idp-tax-how-much-developer-time-your-platform-actually-costs) already pay for every unclear self-service path, just paid again per app instead of once per platform. ZopDay can now skip straight to the destination. A link like `https://zop.dev/zopday/app/deploy?install=wordpress` opens the app directly into the Starter Templates drawer with WordPress already selected. No searching, no catalog browsing, just the install flow for the exact app the link named. ## One Query Param, the Right Drawer Already Open A new hook, `useInstallFromUrl`, reads the `install` query parameter off the URL. The deploy page's drawer component opens Starter Templates preset to whichever chart that parameter names, matched case-insensitively against the catalog so `wordpress`, `WordPress`, and `WORDPRESS` all resolve to the same chart. That match only happens once the catalog has actually finished loading, not against a guess at what the catalog will eventually contain. Once the preset is applied, the parameter gets stripped from the URL, so refreshing the page doesn't reopen the same drawer by accident. Architecture diagram That sequencing matters more than it looks. A preset applied before the catalog loads has nothing real to match against, which is exactly the kind of race condition that would make the feature work in a demo and fail intermittently for an actual teammate on a slower connection. ## The Permission Check Happens Before the Drawer, Not After Not everyone who receives a link is supposed to be able to install anything. A user who opens the link without `PROJECT_CREATE` permission gets a permission-denied toast instead of landing inside a drawer they can look at but can't use. Failing at the permission check, before the drawer ever opens, keeps the error honest: the problem is stated as what it is, a missing permission, rather than surfacing as a drawer that mysteriously won't let anything through. ## A Shareable Link Is Also a New Redirect Target Any link designed to be forwarded and clicked by someone else is also, structurally, a place an attacker would want to insert a different destination. This is a well-documented risk category: [open redirects](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.md) get used to make a phishing link resemble something on a trusted domain. Before this feature could ship, the underlying redirect handling needed hardening. A new `safeReturnTo` helper now threads the intended destination through login, signup, OTP verification, and the GitHub, Google, and SAML OAuth callbacks. It only allows redirect targets that are same-origin and path-relative. | Redirect target | Allowed by safeReturnTo | |---|---| | `/zopday/app/deploy?install=wordpress` (same-origin, path-relative) | Yes | | `https://attacker-site.example/phish` (off-site) | No | | `//attacker-site.example` (protocol-relative, off-site) | No | This works because an install link is exactly the kind of URL people forward without inspecting closely. That makes the login flow a natural target for a redirect that quietly points somewhere else after authentication. Blocking that redirect doesn't cost the convenience: a legitimate install link still carries a user straight through login to the drawer that was preset for them, because that destination is same-origin and path-relative like the table above describes. ## Zero-Org Users Skip a Form They'd Otherwise Have to Fill Out A brand-new user with no org yet used to hit a manual create-org form before doing anything else, including following an install link. That form is now skipped for a zero-org user opening an install link: an org gets created automatically, and they land back on the exact install the link pointed to. Connecting a cloud account, previously a trip out to Settings and back, now renders inline inside the drawer itself, so the whole path from link to running app stays in one place. This ships as a frontend-only change in ZopDay, with no new backend configuration required. Rollback is a plain revert, with one caveat: because the change touches shared authentication files used by every login, signup, and OAuth path, a revert should be paired with a run of the auth test suite, not applied on its own and assumed safe. Try building one yourself: swap `wordpress` in `https://zop.dev/zopday/app/deploy?install=wordpress` for any [chart in the App Catalog](https://zop.dev/resources/blogs/the-idp-tax-180k-year-in-duplicate-tooling) and send the link to a teammate instead of a set of instructions.