chore(express,react,shared): Support dynamic options callback in clerkMiddleware#8398
chore(express,react,shared): Support dynamic options callback in clerkMiddleware#8398wobsoriano merged 21 commits intomainfrom
Conversation
Add ClerkMiddlewareOptionsCallback type so multi-domain/multi-tenant
apps can resolve publishableKey and secretKey per request:
app.use(clerkMiddleware((req) => ({
publishableKey: req.hostname === 'a.com' ? PK_A : PK_B,
secretKey: req.hostname === 'a.com' ? SK_A : SK_B,
})));
Static options path is unchanged. Callback path awaits the function
result and creates the auth handler per request.
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
🦋 Changeset detectedLatest commit: f48bd81 The changes in this PR will be included in the next version bump. This PR includes changesets to release 20 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThis PR enhances the Express middleware to support dynamic, request-based configuration through a callback pattern while introducing a cross-package utility for multi-domain setups. The Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
@clerk/astro
@clerk/backend
@clerk/chrome-extension
@clerk/clerk-js
@clerk/dev-cli
@clerk/expo
@clerk/expo-passkeys
@clerk/express
@clerk/fastify
@clerk/hono
@clerk/localizations
@clerk/nextjs
@clerk/nuxt
@clerk/react
@clerk/react-router
@clerk/shared
@clerk/tanstack-react-start
@clerk/testing
@clerk/ui
@clerk/upgrade
@clerk/vue
commit: |
Derives a production publishable key from the current request hostname,
falling back to the configured key for development instances (pk_test_).
Built on the existing buildPublishableKey and isDevelopmentFromPublishableKey
helpers.
Re-exported from @clerk/react/internal so Replit and other multi-domain
apps can use it without additional dependencies:
import { publishableKeyFromHost } from '@clerk/react/internal'
// React
<ClerkProvider publishableKey={publishableKeyFromHost(window.location.host, process.env.VITE_CLERK_PUBLISHABLE_KEY)}>
// Express (with the new clerkMiddleware callback)
clerkMiddleware((req) => ({
publishableKey: publishableKeyFromHost(req.hostname, process.env.CLERK_PUBLISHABLE_KEY),
}))
Add @clerk/express/internal re-exporting publishableKeyFromHost from
@clerk/shared/keys. Mirrors the @clerk/react/internal pattern.
Also simplifies publishableKeyFromHost to take only host — buildPublishableKey
already handles dev vs prod detection via FAPI host patterns, so no
fallback key parameter is needed.
Usage:
import { publishableKeyFromHost } from '@clerk/express/internal'
clerkMiddleware((req) => ({
publishableKey: publishableKeyFromHost(req.hostname),
}))
Without it, dev instances on localhost produce an incorrect pk_live_ key. If fallbackKey is a pk_test_ key it is returned as-is; otherwise the key is derived from the host for production multi-domain setups.
| if (fallbackKey && isDevelopmentFromPublishableKey(fallbackKey)) { | ||
| return fallbackKey; | ||
| } | ||
| return buildPublishableKey(`clerk.${host.toLowerCase()}`); |
There was a problem hiding this comment.
existing helper that converts a FAPI URL into a base64-encoded publishable key
| @@ -0,0 +1 @@ | |||
| export { publishableKeyFromHost } from '@clerk/shared/keys'; | |||
There was a problem hiding this comment.
🤔 I am a little hesitant to add a whole new entrypoint to a package in a hotfix.. just seems a bit early for this
There was a problem hiding this comment.
are you saying we should just export from @clerk/express or let them import as-is from @clerk/shared/keys?
There was a problem hiding this comment.
For now I think I would suggest they import from @clerk/shared/keys until we are sure this is something we want to re-export from an SDK package.
…e docstring example
…lishableKeyFromHost
Description
Checklist
pnpm testruns as expected.pnpm buildruns as expected.Type of change