packages/prisma/schema/workspace.prisma (1)

42-42: Clarify nullability, rotation, and backfill strategy for publishableKey

publishableKey is optional with a unique constraint. Confirm intent:

• If all projects using client APIs must have a key, consider making it non-nullable and backfilling existing rows.
• If optional by design, document/handle “no key” behavior in middleware.

Also consider:

• Enforcing a bounded length (e.g., @db.VarChar(64/128)) to keep index sizes predictable.
• Establishing a rotation/revocation story (single key vs. multiple keys table).

I can help generate a safe migration/backfill plan if needed.

Would you like me to draft a migration that generates keys for existing projects and adds a uniqueness-preserving index with length bounds?

apps/web/lib/auth/publishable-key.ts (1)

98-101: Consider adding WWW-Authenticate for 401 responses

For better client UX, include WWW-Authenticate: Bearer on 401 Unauthorized responses. If handleAndReturnErrorResponse supports custom headers, set it there for code: "unauthorized" errors.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

apps/web/lib/types.ts (1)

179-189: Redundant redeclaration of publishableKey on ExtendedWorkspaceProps

WorkspaceProps extends Prisma’s Project, which already includes publishableKey (String? → string | null). Redeclaring it here is unnecessary and risks future type drift if the Prisma field changes.

Apply this diff to rely on the base type:

 export interface ExtendedWorkspaceProps extends WorkspaceProps {
   domains: (WorkspaceProps["domains"][number] & {
     linkRetentionDays: number | null;
   })[];
   defaultProgramId: string | null;
   allowedHostnames: string[];
   users: (WorkspaceProps["users"][number] & {
     workspacePreferences?: z.infer<typeof workspacePreferencesSchema>;
   })[];
-  publishableKey: string | null;
 }

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/settings/analytics/allowed-hostnames-form.tsx (2)

98-129: Avoid double-submission; wire Button as submit and disable on processing/permissions

Form onSubmit already calls addHostname(). If Button is type="submit", the onClick handler can cause duplicate calls. Also disable the button on processing and when permission is missing.

Apply this diff:

-      <Button
-        text="Add Hostname"
-        variant="primary"
-        onClick={addHostname}
-        disabled={!isValidHostname(hostname) || hostname.length === 0}
-        loading={processing}
-        className="w-fit"
-        disabledTooltip={permissionsError || undefined}
-      />
+      <Button
+        text="Add Hostname"
+        variant="primary"
+        type="submit"
+        disabled={
+          processing ||
+          !!permissionsError ||
+          !isValidHostname(hostname.trim().toLowerCase())
+        }
+        loading={processing}
+        className="w-fit"
+        disabledTooltip={permissionsError || undefined}
+      />

---

187-203: Disable Delete action during processing and when permission is missing

Prevent repeated PATCH requests and respect permission errors by disabling the button.

Apply this diff:

         <Button
           variant="outline"
           className={cn(
             "h-8 px-1.5 outline-none transition-all duration-200",
             "border-transparent data-[state=open]:border-neutral-500 sm:group-hover/card:data-[state=closed]:border-neutral-200",
           )}
           icon={
             processing ? (
               <LoadingSpinner className="size-4 shrink-0" />
             ) : (
               <Trash className="size-4" />
             )
           }
           onClick={deleteHostname}
+          disabled={processing || !!permissionsError}
           disabledTooltip={permissionsError || undefined}
         />

apps/web/app/(ee)/api/track/sale/client/route.ts (1)

24-29: Prefer schema-level validation over imperative check

customerExternalId emptiness should be enforced in trackSaleRequestSchema (e.g., .min(1)) rather than checked ad hoc here. This removes dead code paths and keeps validation centralized.

Apply this diff after updating the schema as suggested below:

-    if (!customerExternalId) {
-      throw new DubApiError({
-        code: "bad_request",
-        message: "customerExternalId is required",
-      });
-    }

Update the schema (apps/web/lib/zod/schemas/sales.ts) to ensure non-empty values:

// apps/web/lib/zod/schemas/sales.ts
customerExternalId: z
  .string()
  .trim()
  .min(1, "customerExternalId is required")
  .max(100)
  .describe("..."),

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/settings/analytics/publishable-key-form.tsx (1)

25-26: Consider centralizing publishable key generation (optional)

Current setup

• Client generates a key with dub_pk_${nanoid(24)} in
  apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/settings/analytics/publishable-key-form.tsx:25
• Server’s Zod schema (apps/web/lib/zod/schemas/workspaces.ts:150) simply allows any string for publishableKey
• Auth middleware (apps/web/lib/auth/publishable-key.ts:54) only checks that the key starts with "dub_pk_"

Because format logic (client) and validation logic (server) live in separate places, there’s a risk of drift if you ever change the key contract. To keep everything in sync, you might:

• Move key generation to the server-side endpoint
• Extract a shared utility that defines and enforces the key format (both for generation and validation)
• Update the Zod schema and auth middleware to use that shared util

No immediate fixes are required—your current client-generated keys will be accepted as-is. This refactor is purely optional to reduce future maintenance overhead.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/settings/analytics/allowed-hostnames-form.tsx (2)

168-174: Optional: render destructive styling for the confirm action (if supported).

If ConfirmModal supports a destructive variant for the confirm button, consider enabling it to better signal risk.

Example (adjust to actual prop name):

useConfirmModal({
  // ...
  confirmVariant: "destructive",
});

---

176-178: Redundant key prop inside card.

The list key lives on the parent mapping (<AllowedHostnameCard key={hostname} />). The inner key here has no effect and can be removed for clarity.

Apply:

-    <CardList.Card
-      key={hostname}
+    <CardList.Card

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

apps/web/lib/api/cors.ts (1)

1-5: Make headers immutable and add a dynamic preflight helper (+ Vary/Max-Age).

This prevents accidental mutation and makes OPTIONS robust by reflecting Access-Control-Request-Headers. Also add Vary to keep caches honest and Access-Control-Max-Age to cut preflight noise.

Apply this diff for immutability:

-export const COMMON_CORS_HEADERS = {
+export const COMMON_CORS_HEADERS: Readonly<Record<string, string>> = Object.freeze({
   "Access-Control-Allow-Origin": "*",
   "Access-Control-Allow-Methods": "POST, OPTIONS",
   "Access-Control-Allow-Headers":
     "Content-Type, Authorization, X-Dub-Publishable-Key, X-Requested-With",
-};
+});

Add this helper (outside the changed lines; place below the constant):

// Build preflight headers that reflect requested headers to avoid CORS rejections.
export function preflightHeaders(req: Request): Record<string, string> {
  const requested = req.headers.get("Access-Control-Request-Headers") ?? "";
  return {
    ...COMMON_CORS_HEADERS,
    ...(requested && { "Access-Control-Allow-Headers": requested }),
    "Access-Control-Max-Age": "600",
    Vary: "Origin, Access-Control-Request-Headers, Access-Control-Request-Method",
  };
}

apps/web/app/(ee)/api/track/open/route.ts (1)

1-1: Use dynamic preflight headers to mirror requested headers and add Vary/Max-Age.

Hardcoding Access-Control-Allow-Headers can break some clients. Mirror the Access-Control-Request-Headers and expose proper Vary/Max-Age using a helper.

Apply:

-import { COMMON_CORS_HEADERS } from "@/lib/api/cors";
+import { COMMON_CORS_HEADERS, preflightHeaders } from "@/lib/api/cors";

-export const OPTIONS = () => {
-  return new Response(null, {
-    status: 204,
-    headers: COMMON_CORS_HEADERS,
-  });
-};
+export const OPTIONS = (req: Request) =>
+  new Response(null, {
+    status: 204,
+    headers: preflightHeaders(req),
+  });

Also applies to: 138-143

apps/web/app/(ee)/api/shopify/pixel/route.ts (1)

1-1: Prefer dynamic preflight to accommodate Shopify/browser-added headers.

Some storefront setups include additional headers; mirroring requested headers prevents brittle CORS failures.

Apply:

-import { COMMON_CORS_HEADERS } from "@/lib/api/cors";
+import { COMMON_CORS_HEADERS, preflightHeaders } from "@/lib/api/cors";

-export const OPTIONS = () => {
-  return new Response(null, {
-    status: 204,
-    headers: COMMON_CORS_HEADERS,
-  });
-};
+export const OPTIONS = (req: Request) =>
+  new Response(null, {
+    status: 204,
+    headers: preflightHeaders(req),
+  });

Also applies to: 58-63

apps/web/app/(ee)/api/track/click/route.ts (1)

6-6: Align OPTIONS with dynamic preflight; optionally narrow Allow-Origin post-allowlist.

• Dynamic preflight avoids header mismatches.
• Optional: after verifyAnalyticsAllowedHostnames succeeds, consider echoing the request Origin instead of "*" to tighten CORS posture for allowed hosts (logic stays the same; just a response header tweak).

Apply dynamic preflight:

-import { COMMON_CORS_HEADERS } from "@/lib/api/cors";
+import { COMMON_CORS_HEADERS, preflightHeaders } from "@/lib/api/cors";

-export const OPTIONS = () => {
-  return new Response(null, {
-    status: 204,
-    headers: COMMON_CORS_HEADERS,
-  });
-};
+export const OPTIONS = (req: Request) =>
+  new Response(null, {
+    status: 204,
+    headers: preflightHeaders(req),
+  });

If you want to scope Allow-Origin after allowlist verification, I can draft a small helper to conditionally set it based on the Origin header.

Also applies to: 170-175

apps/web/app/api/oauth/token/route.ts (2)

1-1: Use dynamic preflight for OPTIONS to reflect requested headers.

Same rationale as other routes; safer for diverse clients and future header additions.

Apply:

-import { COMMON_CORS_HEADERS } from "@/lib/api/cors";
+import { COMMON_CORS_HEADERS, preflightHeaders } from "@/lib/api/cors";

-export const OPTIONS = () => {
-  return new Response(null, {
-    status: 204,
-    headers: COMMON_CORS_HEADERS,
-  });
-};
+export const OPTIONS = (req: Request) =>
+  new Response(null, {
+    status: 204,
+    headers: preflightHeaders(req),
+  });

Also applies to: 32-37

---

19-21: Double-check CORS exposure for the token endpoint fits your threat model.

Allow-Origin: "*" on a token endpoint is a product decision. If tokens are intended to be retrievable by browsers from arbitrary origins (e.g., SPA + PKCE), this is fine. If not, consider restricting origins or disabling CORS here.

I can draft an Origin-allowlist solution keyed off environment config if you’d like.

Also applies to: 24-26

apps/web/app/(ee)/api/track/visit/route.ts (3)

2-2: CORS centralization is good; double-check allowed headers for publishable-key flows

Importing COMMON_CORS_HEADERS reduces drift—nice. One caution: If client endpoints authenticated via a “publishable key” use a custom header (e.g., X-Dub-Publishable-Key), ensure COMMON_CORS_HEADERS["Access-Control-Allow-Headers"] includes it; otherwise, browsers will block cross-origin requests at preflight.

Proposed update in apps/web/lib/api/cors.ts:

 export const COMMON_CORS_HEADERS = {
   "Access-Control-Allow-Origin": "*",
   "Access-Control-Allow-Methods": "POST, OPTIONS",
-  "Access-Control-Allow-Headers": "Content-Type, Authorization",
+  "Access-Control-Allow-Headers": "Content-Type, Authorization, X-Dub-Publishable-Key",
+  // Optional: reduce preflight chatter across busy tracking endpoints
+  "Access-Control-Max-Age": "86400",
 };

If the publishable key is carried via Authorization: Bearer ..., this change isn’t strictly required—please confirm what withPublishableKey expects.

---

107-108: Final JSON response uses common CORS — LGTM

Consistent header application on the success path. Consider adding a Cache-Control header if you ever want clients/CDNs to cache this short-lived response, but not required.

---

118-119: OPTIONS 204 with common CORS — LGTM; consider max-age

Preflight handling is correct. If you adopt Access-Control-Max-Age in COMMON_CORS_HEADERS, this OPTIONS response will benefit automatically.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

apps/web/app/(ee)/api/track/lead/client/route.ts (3)

56-56: Propagate rate limit headers on success (see sale route comment)

Mirror the middleware-level fix so clients can read remaining quota. No action needed in this file if publishable-key middleware merges headers as suggested.

---

59-66: Avoid plan list duplication; centralize allowed plans

Same refactor as previously suggested; import from a single constants module.

---

6-6: Add Vary header in COMMON_CORS_HEADERS (shared)

As noted in the sale route, add Vary: Origin, Authorization to the shared CORS headers to make client routes safe around caches.

apps/web/app/(ee)/api/track/sale/client/route.ts (6)

30-39: Prefer const for parsed request props

These values aren’t reassigned. Use const for clarity and to prevent accidental mutation.

-    let {
+    const {
       customerExternalId,
       paymentProcessor,
       invoiceId,
       amount,
       currency,
       metadata,
       eventName,
       leadEventName,
     } = trackSaleRequestSchema.parse(body);

---

6-6: Add Vary: Origin, Authorization to CORS headers to prevent cache key collisions

Since Authorization carries the publishable key (per learning) and Origin affects allowlisting, add Vary to avoid cross-tenant leakage via intermediary caches/CDNs. Optional: add Access-Control-Max-Age to reduce preflight cost.

apps/web/lib/api/cors.ts:

 export const COMMON_CORS_HEADERS = {
   "Access-Control-Allow-Origin": "*",
   "Access-Control-Allow-Methods": "POST, OPTIONS",
   "Access-Control-Allow-Headers": "Content-Type, Authorization",
+  "Vary": "Origin, Authorization",
+  "Access-Control-Max-Age": "600",
 };

Note: This aligns with the publishable key sent via Authorization: Bearer dub_pk_… as captured in the retrieved learnings.

---

24-27: Avoid hard-coding app.dub.co; centralize app origin

Use a single source of truth (e.g., APP_ORIGIN from config/constants) to build links in error messages. This prevents environment-specific leaks (staging, self-hosted) and eases future moves.

Example:

- message: `Request origin '${getHostnameFromRequest(req)}' is not included in the allowed hostnames for this workspace. Update your allowed hostnames here: https://app.dub.co/settings/analytics`,
+ message: `Request origin '${getHostnameFromRequest(req)}' is not included in the allowed hostnames for this workspace. Update your allowed hostnames here: ${APP_ORIGIN}/settings/analytics`,

---

64-71: Avoid plan list duplication; centralize allowed plans

Same list appears in multiple routes and defaults in middleware. Move to a shared constant (e.g., "@/lib/plans") to prevent drift and enable normalization (e.g., lowercasing) in one place.

---

61-61: Add rate‐limit headers to successful responses in withPublishableKey

Currently, withPublishableKey only applies the computed X-RateLimit-* and Retry-After headers when returning a 429 response. On successful requests the wrapper returns the handler’s Response (or object) without those headers, so downstream routes cannot inspect remaining quota.

To address this, update apps/web/lib/auth/publishable-key.ts to merge the headers object onto all successful handler results:

• File: apps/web/lib/auth/publishable-key.ts
– After calling the handler, detect if the returned value is a Response and set each header.
– Otherwise, wrap non-Response returns in a new Response with the headers applied.

Illustrative diff:

--- a/apps/web/lib/auth/publishable-key.ts
+++ b/apps/web/lib/auth/publishable-key.ts
@@ after line ~70
-          const searchParams = getSearchParams(req.url);
-          return await handler({ req, params, searchParams, workspace });
+          const searchParams = getSearchParams(req.url);
+          // Invoke handler and propagate rate-limit headers on all responses
+          const result = await handler({ req, params, searchParams, workspace });
+          // If it's already a Response, merge headers
+          if (result instanceof Response) {
+            for (const [key, value] of Object.entries(headers)) {
+              result.headers.set(key, value as string);
+            }
+            return result;
+          }
+          // Otherwise wrap the response data
+          return new Response(JSON.stringify(result), {
+            status: 200,
+            headers: {
+              "content-type": "application/json",
+              ...headers,
+            },
+          });

This change ensures all successful endpoints receive consistent rate-limit metadata without each route needing to handle it.

---

41-46: Centralize non-empty customerExternalId validation in your Zod schema and remove the runtime guard

To avoid divergent error messages and duplicated checks, move the “required and non-empty” validation into trackSaleRequestSchema and drop the manual guard in the route.

• In apps/web/lib/zod/schemas/sales.ts, update the customerExternalId definition:

- customerExternalId: z
-   .string()
-   .trim()
-   .max(100)
+ customerExternalId: z
+   .string({ required_error: "customerExternalId is required" })
+   .trim()
+   .min(1, "customerExternalId is required")
+   .max(100)

• In apps/web/app/(ee)/api/track/sale/client/route.ts, remove the manual guard at lines 41–46:

-    if (!customerExternalId) {
-      throw new DubApiError({
-        code: "bad_request",
-        message: "customerExternalId is required",
-      });
-    }

This ensures all “required and non-empty” logic lives in one place and yields consistent error messages.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: steven-tey
PR: dubinc/dub#2737
File: apps/web/lib/api/cors.ts:1-5
Timestamp: 2025-08-21T03:03:39.825Z
Learning: Dub publishable keys are sent via Authorization header using Bearer token format, not via custom X-Dub-Publishable-Key header. The publishable key middleware extracts keys using req.headers.get("Authorization")?.replace("Bearer ", "") and validates they start with "dub_pk_".