fix: built-in plugin dalle3 error #5787

[JingSyue]

💻 变更类型 | Change Type

• feat
• fix
• refactor
• perf
• style
• test
• docs
• ci
• chore
• build

🔀 变更说明 | Description of Change

feat: support dalle3 api key from server env

Added OpenAI API key handling in proxy route for DALL-E 3 requests.
Securely fetches API key from server environment variables
instead of requiring client-side key.

Changes:

• Add getServerSideConfig import in proxy.ts
• Add OpenAI API key check and injection for requests to api.openai.com
• Maintain key security by only accessing env vars server-sid

Bug Fixes: builtin plugin dalle3 can't not use openai api key

📝 补充信息 | Additional Information

Relevant issue：#5787

Summary by CodeRabbit

• New Features

  • Enhanced authorization mechanism for requests to the OpenAI API, improving security and functionality.

• Bug Fixes

  • Updated request handling to include conditional checks for specific headers, ensuring proper processing.

[vercel]

Someone is attempting to deploy a commit to the NextChat Team on Vercel.

A member of the Team first needs to authorize it.

[coderabbitai]

Walkthrough

The changes in this pull request focus on enhancing the handle function within app/api/proxy.ts. A new import for getServerSideConfig is added, allowing the function to retrieve server-side configuration details. The authorization mechanism is updated to conditionally set an Authorization header for requests with the x-base-url header containing "api.openai.com", utilizing an API key from the server configuration. The overall structure for processing requests remains unchanged, with existing timeout handling and response processing retained.

Changes

File	Change Summary
app/api/proxy.ts	- Added import for getServerSideConfig. - Updated handle function to include new authorization logic based on x-base-url header. - Maintained existing request processing and response handling.

Possibly related PRs

• fix: #5429 Anthropic authentication_error CORS #5435: Modifies request headers in app/api/anthropic.ts, related to authorization mechanisms similar to those in the handle function.
• hotfix for x-goog-api-key #5562: Updates how authorization tokens are retrieved in app/api/google.ts, aligning with the enhancements in the authorization logic of the main PR.

Suggested reviewers

• Dogtiti
• lloydzhou

🐇 In the meadow, where bunnies play,
A new feature hops in, brightening the day.
With tokens and headers, we dance and we sing,
Enhancing our proxy, oh what joy it brings!
So let’s fetch the data, with a hop and a cheer,
For the OpenAI calls, we now have no fear! 🌼

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 1

🧹 Outside diff range and nitpick comments (1)

app/api/proxy.ts (1)

Line range hint 1-83: Security enhancement confirmation

The implementation successfully addresses the security concern by moving the OpenAI API key handling to the server side. This change:

1. Prevents client-side exposure of the API key
2. Maintains proper header sanitization
3. Preserves existing security measures

Consider adding request logging for security monitoring.

Add debug logging for security monitoring:

   if (baseUrl?.includes("api.openai.com")) {
+    console.log("[Proxy Route] Handling OpenAI API request");
     headers.set("Authorization", `Bearer ${serverConfig.apiKey}`);
   }

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 108069a and 2b0f2e5.

📒 Files selected for processing (1)

• app/api/proxy.ts (3 hunks)

🔇 Additional comments (2)

app/api/proxy.ts (2)

2-2: LGTM: Secure server-side configuration handling

The addition of server-side configuration handling is well-placed and follows security best practices by keeping sensitive data server-side.

Also applies to: 13-13

---

Line range hint 41-83: Verify impact on other API endpoints

The proxy implementation looks robust, but let's ensure the new OpenAI-specific changes don't affect other API endpoints.

✅ Verification successful

Let me gather more information about the API endpoints and their implementations.

---

Based on the comprehensive analysis of the codebase, I can now provide a final response regarding the impact of the OpenAI-specific changes on other API endpoints.

Content-encoding header removal is safe for other endpoints

The changes to handle content-encoding are specific to OpenAI's API behavior and won't affect other endpoints because:

• The content-encoding header removal is only implemented in the proxy route which is used exclusively by OpenAI endpoints (verified by checking x-base-url usage)
• Other API providers (Anthropic, Google, Azure, etc.) have their own dedicated route handlers with separate header management
• Each provider's route handler implements its own header sanitization specific to that provider's needs

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for other API endpoints that might be affected by these changes

# Look for other API endpoint configurations or usages
echo "Checking for other API endpoint configurations..."
rg -l "x-base-url" --type ts

# Look for other proxy route handlers
echo "Checking for other proxy implementations..."
ast-grep --pattern 'export async function handle(req: NextRequest, $$$)'

Length of output: 326

---

Script:

#!/bin/bash
# Search for all route handlers in the API directory
echo "Checking API route handlers..."
fd . app/api -t f -e ts -x cat {}

# Search for fetch implementations
echo "Checking fetch implementations..."
ast-grep --pattern 'fetch($_, $_)'

Length of output: 70205

[coderabbitai]

🛠️ Refactor suggestion

Enhance API key injection robustness

While the implementation addresses the core issue, consider these improvements for better reliability:

1. Use a more specific check for OpenAI endpoints
2. Add validation for the API key
3. Include proper error handling

Consider this enhanced implementation:

-  if (req.headers.get("x-base-url")?.includes("openai")) {
-    headers.set("Authorization", `Bearer ${serverConfig.apiKey}`);
+  const baseUrl = req.headers.get("x-base-url");
+  if (baseUrl?.includes("api.openai.com")) {
+    if (!serverConfig.apiKey) {
+      return NextResponse.json(
+        { error: "OpenAI API key not configured" },
+        { status: 500 }
+      );
+    }
+    headers.set("Authorization", `Bearer ${serverConfig.apiKey}`);
   }

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	// if dalle3 use openai api key
	if (req.headers.get("x-base-url")?.includes("openai")) {
	headers.set("Authorization", `Bearer ${serverConfig.apiKey}`);
	}
	// if dalle3 use openai api key
	const baseUrl = req.headers.get("x-base-url");
	if (baseUrl?.includes("api.openai.com")) {
	if (!serverConfig.apiKey) {
	return NextResponse.json(
	{ error: "OpenAI API key not configured" },
	{ status: 500 }
	);
	}
	headers.set("Authorization", `Bearer ${serverConfig.apiKey}`);
	}

[lloydzhou]

includes('api.openai.com')

[coderabbitai]

Actionable comments posted: 0

🧹 Outside diff range and nitpick comments (1)

app/api/proxy.ts (1)

36-46: Add documentation for the API key injection logic

Consider adding a comment block explaining the DALL-E 3 specific handling and the security implications of server-side API key management.

+ // DALL-E 3 requests require server-side API key injection
+ // We only inject the key for api.openai.com to prevent key leakage
  const baseUrl = req.headers.get("x-base-url");

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 2b0f2e5 and 18a6571.

📒 Files selected for processing (1)

• app/api/proxy.ts (3 hunks)

🔇 Additional comments (2)

app/api/proxy.ts (2)

Line range hint 2-13: LGTM: Clean server configuration integration

The server-side configuration is properly imported and initialized early in the request handling flow, following good practices for configuration management.

---

36-46: Verify error handling behavior

The API key injection logic looks secure, but let's verify the error handling behavior in various scenarios.

Let's verify the error handling implementation:

✅ Verification successful

Error handling implementation is secure and consistent

The error handling for the OpenAI API key is properly implemented:

• Returns a clear, non-revealing error message when API key is missing
• Uses appropriate HTTP 500 status code for server configuration issues
• Consistently checks for API key presence before using it
• No sensitive information is exposed in error messages

The implementation aligns with security best practices for API key handling and error responses.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify error handling for OpenAI API requests
# Test cases:
# 1. Check for proper error message construction
# 2. Verify no sensitive information in error responses

# Search for other error handling patterns in the codebase
rg -A 2 'OpenAI API key not configured'

# Check for any potential sensitive information leakage in error messages
rg -g '*.ts' -g '*.js' 'serverConfig.apiKey.*error'

Length of output: 238

---

Script:

#!/bin/bash
# Let's perform a more comprehensive check of error handling patterns

# Check for all error responses in the proxy endpoint
rg -A 5 'NextResponse.json.*error' app/api/proxy.ts

# Look for other uses of serverConfig.apiKey to ensure consistent error handling
rg -A 3 'serverConfig.apiKey' 

# Check the structure of serverConfig to understand the API key handling
ast-grep --pattern 'const serverConfig = {
  $$$
}'

Length of output: 820

[github-actions]

Your build has completed!

Preview deployment