fix(docker): allow MARBLE_WORKSPACE_KEY to be passed during build#712
fix(docker): allow MARBLE_WORKSPACE_KEY to be passed during build#712xandyxor wants to merge 1 commit intoOpenCut-app:mainfrom
Conversation
|
@xandyxor is attempting to deploy a commit to the OpenCut OSS Team on Vercel. A member of the Team first needs to authorize it. |
📝 WalkthroughWalkthroughThe Dockerfile was updated to introduce a build-time argument for Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/web/Dockerfile`:
- Line 35: Remove the hardcoded default workspace key: change the Dockerfile ENV
declaration so MARBLE_WORKSPACE_KEY is not set to a literal default (stop using
ENV MARBLE_WORKSPACE_KEY=${MARBLE_WORKSPACE_KEY:-cmd4iw9mm0006l804kwqv0k46});
instead require a build-arg or use Docker build secrets (e.g., use --build-arg
MARBLE_WORKSPACE_KEY=... at build time or RUN --mount=type=secret,id=marble_key
ENV MARBLE_WORKSPACE_KEY=$(cat /run/secrets/marble_key)). Also remove the
fallback hardcoded key in the client code (the fallback in
apps/web/src/lib/blog/query.ts) and make code that reads
process.env.MARBLE_WORKSPACE_KEY fail loudly or throw a clear error when the env
var is missing so the secret must be injected at runtime.
| ENV NEXT_PUBLIC_SITE_URL="http://localhost:3000" | ||
| ENV NEXT_PUBLIC_MARBLE_API_URL="https://api.marblecms.com" | ||
| ENV MARBLE_WORKSPACE_KEY="build-placeholder" | ||
| ENV MARBLE_WORKSPACE_KEY=${MARBLE_WORKSPACE_KEY:-cmd4iw9mm0006l804kwqv0k46} |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Search for references to MARBLE_WORKSPACE_KEY in the codebase
rg -i "MARBLE_WORKSPACE_KEY" --context 3Repository: OpenCut-app/OpenCut
Length of output: 2849
🏁 Script executed:
# Look for any documentation about Marble or this key
find . -type f \( -name "README*" -o -name "*.md" -o -name "*.txt" \) | head -20 | xargs grep -l -i "marble\|workspace" 2>/dev/nullRepository: OpenCut-app/OpenCut
Length of output: 100
🏁 Script executed:
# Check if there are any comments in the Dockerfile itself
cat -n apps/web/DockerfileRepository: OpenCut-app/OpenCut
Length of output: 2459
🌐 Web query:
Marble CMS workspace key public or sensitive
💡 Result:
Marble CMS workspace key should be treated as sensitive (a secret), not public.
Marble’s API docs state that requests are authenticated using the workspace key in the URL path, and explicitly warn: “Your workspace key carries many privileges, so be sure to keep it secure! Do not share your workspace key in publicly accessible areas such as GitHub, client-side code…” [1]. If you need a value that can be exposed, use a scoped API key instead (ideally server-side), since even “public/read-only” keys can still be abused (e.g., consuming rate limits) [2].
Sources: [1] [2]
🌐 Web query:
Marble API marblecms.com workspace authentication
💡 Result:
Marble CMS (marblecms.com) authenticates API requests with an API key tied to your workspace:
- Create/manage the key: In your workspace dashboard go to Settings → API Keys. [1]
- Send the key on every request (recommended): Put it in the
Authorizationheader. [1]curl -H "Authorization: YOUR_API_KEY" \ https://api.marblecms.com/v1/posts - Alternative (less recommended): Pass it as a query parameter
?key=YOUR_API_KEY. [1]curl "https://api.marblecms.com/v1/posts?key=YOUR_API_KEY"
If you tell me what you mean by “workspace authentication” (e.g., selecting a workspace in API calls, user login/OAuth, or server-to-server API access), I can point to the exact endpoint/headers for that. [1]
Remove the default MARBLE_WORKSPACE_KEY or move it to secret injection.
Per Marble CMS documentation, workspace keys are sensitive secrets and must not be committed to publicly accessible repositories. The key cmd4iw9mm0006l804kwqv0k46 is now baked into the Docker image layer at build time and also hardcoded in apps/web/src/lib/blog/query.ts as a fallback. Marble explicitly warns: "Your workspace key carries many privileges, so be sure to keep it secure! Do not share your workspace key in publicly accessible areas such as GitHub, client-side code…"
Either:
- Remove the default entirely and require
--build-arg MARBLE_WORKSPACE_KEY=...at build time, or - Use Docker build secrets:
RUN --mount=type=secret,id=marble_key ENV MARBLE_WORKSPACE_KEY=$(cat /run/secrets/marble_key)
Also remove the hardcoded default from apps/web/src/lib/blog/query.ts and require the env var to be set at runtime.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/web/Dockerfile` at line 35, Remove the hardcoded default workspace key:
change the Dockerfile ENV declaration so MARBLE_WORKSPACE_KEY is not set to a
literal default (stop using ENV
MARBLE_WORKSPACE_KEY=${MARBLE_WORKSPACE_KEY:-cmd4iw9mm0006l804kwqv0k46});
instead require a build-arg or use Docker build secrets (e.g., use --build-arg
MARBLE_WORKSPACE_KEY=... at build time or RUN --mount=type=secret,id=marble_key
ENV MARBLE_WORKSPACE_KEY=$(cat /run/secrets/marble_key)). Also remove the
fallback hardcoded key in the client code (the fallback in
apps/web/src/lib/blog/query.ts) and make code that reads
process.env.MARBLE_WORKSPACE_KEY fail loudly or throw a clear error when the env
var is missing so the secret must be injected at runtime.
1 participant
This PR fixes the Docker build failure during the next build stage.
The Problem:
The Dockerfile previously used a hardcoded "build-placeholder" for MARBLE_WORKSPACE_KEY. Since Next.js performs static generation during build time, it attempts to fetch blog data. An invalid key results in a 404 Not Found error, causing the build to fail.
The Solution:
Added ARG MARBLE_WORKSPACE_KEY to the Dockerfile.
Changed ENV MARBLE_WORKSPACE_KEY to use the passed argument with a working default value.
Summary by CodeRabbit
Note: This is an infrastructure update with no end-user visible changes.