@eridian-ai/designer
v0.2.0
Published
Designer customer-side integration: identity-assertion verify + npx designer doctor
Maintainers
Readme
@eridian-ai/designer
Lets your users describe a UI change and get it, in a fork of your own app at their own URL. This package is the entire integration on your side: two functions and one middleware line.
Zero dependencies. Additive and fail-closed — merge it and nothing about your app changes until you turn Designer on.
pnpm add @eridian-ai/designer
npx designer doctor # check your app is ready, before anyone forks itWhat Designer needs from you
A fork of your app runs in a sandbox that holds no secrets — no database URL, no session cookie, no API key. So it cannot look a user up. Instead Designer's router attaches a short-lived Ed25519 assertion to every request it proxies, and you verify it with a public key.
You are verifying us. We never hold a credential of yours.
1. Let assertion-carrying requests past your middleware
A fork request has no cookie, so your middleware would bounce it to your login page before anything could verify it.
import { hasDesignerAssertion } from "@eridian-ai/designer";
export function middleware(request: NextRequest) {
if (hasDesignerAssertion(request.headers)) return NextResponse.next();
// ...your existing checks
}2. Resolve it in your server session lookup
import { resolveDesignerAssertion } from "@eridian-ai/designer";
export async function getSession() {
const h = await headers();
const user = await resolveDesignerAssertion(h, {
// Bind the assertion to this deployment. Designer supplies the generic
// value inside fork runtimes.
expectedSiteId: process.env.ERIDIAN_DESIGNER_SITE_ID,
// Your own lookup. Runs at mainline; skipped inside a sandbox, which has
// no database to run it against. Match the column the subject comes from:
// the one your embed handoff mints `externalId` from, or "email" when
// your handoff omits `externalId`.
resolveUser: (subject) =>
db.selectFrom("user").select(["id", "email", "name"])
.where("id", "=", subject).executeTakeFirst(),
});
if (user) return sessionFor(user);
// ...your existing cookie session, untouched
}That is the whole runtime contract.
Why this is safe to merge
- Inert until you opt in. Everything returns
nullunlessERIDIAN_DESIGNER_ASSERTION_PUBLIC_KEYis set. Merge it, deploy it, observe no change. - Fail-closed. No header →
null, and your normal session runs. A bad signature, wrong site, missing site configuration, wrong audience, expired token, or over-long lifetime →null. Never a partial trust. - Nothing to replay. The assertion rides the proxy hop, never the page. A browser cannot see one, and could not forge one if it did.
- Your authorization still decides. Inside a sandbox the assertion resolves your app's shell; every byte of data it displays still comes from your own API, which runs this same verification and your own lookup before answering.
npx designer doctor
Checks the things that otherwise fail silently, in your terminal instead of in front of a user:
- your
@sourcestylesheet paths resolve (an unresolvable one produces a valid stylesheet missing every class used only by your shared components) - which workspace packages your app needs — the exact set a fork's workspace must contain, since a missing one installs fine and then fails to import
- your server routes, which Designer proxies to your backend
- your middleware lets fork requests through
--build: your app builds with no environment variables at all, and how much CSS that build emits
