jchris/vibes popup

[jchris]

Summary

This PR implements a popup-based JWT token exchange system to allow trusted 3rd-party applications to securely authenticate with the vibes.diy backend.

Problem

External applications (like Strudel) need to make authenticated requests to our API. However:

1. Clerk tokens are short-lived (30s) and difficult to refresh from a cross-origin context without a popup.
2. We cannot expose long-lived secrets to client-side apps.
3. The backend requires valid authentication for AI generation endpoints.

Solution

We introduce a "Token Provider" popup flow:

1. The 3rd-party app opens https://vibes.diy/auth/token-provider in a popup.
2. This internal route (authenticated via Clerk) continually exchanges a fresh Clerk token for a signed Vibes JWT via a new backend endpoint.
3. The Vibes JWT is sent back to the parent window via postMessage.
4. The 3rd-party app uses this token in the Authorization header (or X-Vibes-Token) for API calls.

Key Changes

Backend (hosting/pkg)

• New Endpoint: POST /api/auth/exchange-token
  • Validates the user's Clerk session.
  • Issues a short-lived (60s) JWT signed with CLERK_SECRET_KEY.
• New Middleware: vibesTokenMiddleware
  • Checks for X-Vibes-Token or Authorization: Bearer ....
  • Validates the custom JWT signature.
  • Sets the user context, acting as a fallback to standard Clerk middleware.
• Integration: Registered the new endpoint and middleware in index.ts.

Frontend (vibes.diy/pkg)

• New Route: /auth/token-provider
  • A minimal React component that handles the token exchange loop (refreshing every 30s).
  • Whitelists parent origins (e.g., localhost, strudel.cc).
  • communicating tokens via window.opener.postMessage.
• Routing: Added the route to routes.ts.

[netlify]

✅ Deploy Preview for fireproof-ai-builder canceled.

Name	Link
🔨 Latest commit	2388bf4
🔍 Latest deploy log	https://app.netlify.com/projects/fireproof-ai-builder/deploys/692b492e5575cb000805a5e5

[github-actions]

🎉 Hosting Preview Deployment

Preview URL: https://pr-676-vibes-hosting-v2.jchris.workers.dev
Worker: pr-676-vibes-hosting-v2
Commit: d48602f

Test the preview:

1. Visit the preview URL above
2. Test hosting functionality (KV assets, queue operations)
3. Verify API integrations work correctly
4. Check domain routing is disabled (workers.dev only)

---

_{This preview will be automatically updated on each push to this PR}

[charliecreates]

Overall the changes are cohesive and line up with the documented JWT token-exchange design, but there are a few security and maintainability concerns around key management and popup origin handling. The server-side code currently reuses CLERK_SECRET_KEY for signing custom vibes JWTs, which is workable but couples responsibilities and makes rotation harder. On the client side, the token-provider popup is permissive when window.opener is missing and when origins are invalid, which should be tightened to "fail closed" for a security-sensitive cross-window messaging path. The new installs grid and icon usage look logically sound, with only a minor UX consideration around the updated "Shared with" label. Addressing the noted issues will make the auth flow more robust and reduce future debugging/security risks.

Additional notes (2)

• Maintainability | hosting/pkg/src/middleware/vibesTokenAuth.ts:69-76
  Right now, a failure to verify the vibes token is silently ignored for short-ish tokens (vibesToken.length <= 20), which could mask malformed/empty headers or configuration mistakes. That makes debugging 3rd-party integrations harder and may result in subtle auth issues where requests unexpectedly run unauthenticated. You already avoid log spam for clearly bogus tokens, so it would be safer to at least log once for obviously invalid formats (e.g., missing sections) or always log at debug level while keeping the warning-level guard for long, likely real tokens.

• Maintainability | vibes.diy/pkg/app/routes/auth.token-provider.tsx:30-43
  The origin whitelist is hard-coded here, including specific third-party domains (strudel.cc, strudel.fp). That’s fine initially, but as you add or change consumers it requires code changes and redeploys. It also mixes configuration with logic, which makes auditing which apps are allowed more difficult.

Since this route is core to 3rd-party auth, moving the allowed-origins list into configuration (env or a shared config module) would make it easier to manage and reason about, and better match the design doc’s emphasis on security.

Summary of changes

Summary of Changes

• Updated OpenAI image generation size from 512x512 to the DALL-E 3–compatible 1024x1024.
• Added a new /api/auth/exchange-token endpoint that exchanges a Clerk-authenticated user session for a short-lived vibes JWT.
• Introduced vibesTokenMiddleware to authenticate requests via a X-Vibes-Token or Authorization: Bearer JWT, as a fallback to Clerk.
• Wired the new auth pieces into the hosting API router, including route registration for the token exchange endpoint and middleware.
• Added detailed documentation (notes/fix-login.md) describing the 3rd-party JWT token-exchange architecture and flow.
• Added a new frontend route /auth/token-provider that runs in a popup, maintains a Clerk session, exchanges Clerk tokens for vibes JWTs, and posts them to the opener.
• Updated the installs route UI to render installs as a responsive grid of PublishedVibeCard components with icon support and slightly simplified metadata display.
• Updated the app routes configuration to register the new auth/token-provider route.

[charliecreates]

Using CLERK_SECRET_KEY as the signing key for your own vibes JWTs couples your internal token format to Clerk and effectively turns that key into a generic HMAC secret for a broader surface area. That increases blast radius if the Clerk secret is ever rotated or leaked, and makes it harder to change auth providers later. A dedicated VIBES_JWT_SECRET (or similar) gives you clearer separation of concerns and lets you rotate or scope keys independently while still keeping the current design.

Additionally, the hard-coded 60 seconds TTL is fine for now but would be easier to tune and monitor if it were driven by configuration (e.g., an env var) rather than an inline literal.

Suggestion

Consider introducing a dedicated signing secret and configurable expiry instead of hard-coding CLERK_SECRET_KEY and 60 here. For example:

const secretKey = c.env.VIBES_JWT_SECRET || c.env.CLERK_SECRET_KEY;
const secret = new TextEncoder().encode(secretKey);
const expiresIn = Number(c.env.VIBES_JWT_TTL_SECONDS ?? 60);

and document that VIBES_JWT_SECRET is preferred going forward. Reply with "@CharlieHelps yes please" if you'd like me to add a commit with this change wired through and documented.

[charliecreates]

Same as in AuthExchangeToken, this middleware uses CLERK_SECRET_KEY as the shared secret for verifying vibes JWTs. From a security and separation-of-concerns standpoint, it's better to sign and verify these tokens with a dedicated secret so that Clerk's secret isn't directly exposed to 3rd-party-token concerns and can be rotated or scoped independently.

Changing this now is low-cost and keeps your auth surfaces cleaner.

Suggestion

Align this verifier with a dedicated vibes JWT secret:

const rawSecret = c.env.VIBES_JWT_SECRET ?? c.env.CLERK_SECRET_KEY;
if (!rawSecret) {
  // If you don't want to 500 here, at least log loudly
  console.error("Missing JWT signing secret (VIBES_JWT_SECRET/CLERK_SECRET_KEY)");
  return next();
}
const secret = new TextEncoder().encode(rawSecret);
const { payload } = await jwtVerify<VibesTokenPayload>(
  vibesToken,
  secret,
  { issuer: "vibes.diy", audience: "vibes.diy-api" },
);

This keeps signing and verification logic consistent and allows you to rotate VIBES_JWT_SECRET without touching Clerk. Reply with "@CharlieHelps yes please" if you'd like me to add a commit with this suggestion.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Handle cross-origin parent without DOMException

The token-provider popup reads window.opener?.location?.origin to decide whether to trust the opener. When this window is opened from a different origin (the main exchange scenario), browsers throw a DOMException on that property due to cross-origin restrictions, so the effect fails before it can whitelist the origin or post a token. As a result, popups launched from strudel.cc or other third-party hosts will crash and never deliver a JWT. Guard the origin lookup with a try/catch or use a safer source like document.referrer/postMessage.

Useful? React with 👍 / 👎.