Propagate client IP header if received in request

[felixkob]

No description provided.

[claude]

Claude finished @felixkob's task —— View job

---

Claude Code has reviewed this PR

Review Checklist:

• Check for repo-specific guidelines (CLAUDE.md)
• Read and analyze the changed files
• Review code quality and best practices
• Check for potential bugs or issues
• Assess performance considerations
• Evaluate security concerns
• Review test coverage

Pull Request Review

Summary

This PR adds functionality to propagate the Base44-Client-IP header from incoming requests through to API calls made by the SDK. This is a useful feature for tracking the original client IP address through proxy layers.

Code Quality and Best Practices ✅

The implementation follows existing patterns in the codebase:

• Proper header extraction and validation in createClientFromRequest (src/client.ts:223)
• Conditional header propagation only when present (src/client.ts:262-265)
• Consistent use of the existing headers parameter in createClient (src/client.ts:273)

Potential Issues 🟡

1. Missing PR Description: The PR lacks a description explaining the motivation and use cases for this feature. This makes it harder for reviewers and future maintainers to understand the context.

2. No TypeScript types update: The createClient function's headers parameter is already typed as Record<string, string>, which is good. However, consider documenting the expected headers in the JSDoc comment.

Performance Considerations ✅

The implementation has minimal performance impact:

• Only creates the additionalHeaders object when the header is present
• No additional processing or validation overhead

Security Considerations ⚠️

1. IP Spoofing Risk: The Base44-Client-IP header can be spoofed by clients. This implementation trusts the header value without validation. Consider:

   • Documenting that this header should only be trusted when coming from known proxy/gateway sources
   • Adding configuration to optionally validate or sanitize IP addresses
   • Warning users about the security implications in documentation

2. Header Propagation: The implementation correctly propagates the header to all API calls, which could expose internal client IPs to the Base44 API. Ensure this is intentional and documented.

Test Coverage ✅

Excellent test coverage has been added:

• Tests verify header propagation when present (tests/unit/client.test.js:223-241)
• Tests confirm no header when absent (tests/unit/client.test.js:243-260)
• Integration tests with nock verify headers are passed correctly to API calls (tests/unit/client.test.js:457-551)
• Tests cover both user and service role scenarios

Recommendations

1. Add a PR description explaining:

   • Why this feature is needed
   • Example use cases
   • Any security considerations

2. Consider adding JSDoc documentation to the createClient function about the headers parameter and specifically mention Base44-Client-IP as a supported header.

3. Add documentation or code comments warning about IP spoofing risks and when to trust this header.

4. Consider adding optional IP validation/sanitization to prevent malformed IP addresses from being propagated.

Overall, this is a well-implemented feature with excellent test coverage. The main concerns are around documentation and security considerations that should be addressed.

[github-actions]

🚀 Package Preview Available!

---

Install this PR's preview build with npm:

npm i @base44-preview/sdk@0.8.4-pr.53.42553d8

Prefer not to change any import paths? Install using npm alias so your code still imports @base44/sdk:

npm i "@base44/sdk@npm:@base44-preview/sdk@0.8.4-pr.53.42553d8"

Or add it to your package.json dependencies:

{
  "dependencies": {
    "@base44/sdk": "npm:@base44-preview/sdk@0.8.4-pr.53.42553d8"
  }
}

• 📦 Preview Package: @base44-preview/sdk@0.8.4-pr.53.42553d8
• 🔗 View this commit on GitHub

---

_{Preview published to npm registry — try new features instantly!}

[claude]

Claude finished @felixkob's task —— View job

---

Pull Request Review

I've analyzed the changes in this PR. The implementation has been updated since the initial review - the header was renamed from Base44-Client-IP to Base44-State.

Review Checklist:

• Check for repo-specific guidelines (CLAUDE.md)
• Read and analyze the changed files
• Review code quality and best practices
• Check for potential bugs or issues
• Assess performance considerations
• Evaluate security concerns
• Review test coverage

Summary

This PR adds functionality to propagate the Base44-State header (previously Base44-Client-IP) from incoming requests through to API calls made by the SDK. The header appears to be used for propagating client IP addresses through proxy layers.

Code Quality and Best Practices ✅

The implementation is clean and follows existing patterns:

• Proper header extraction in createClientFromRequest (src/client.ts:223)
• Conditional header propagation only when present (src/client.ts:262-265)
• Consistent use of the existing headers parameter in createClient
• Code style matches the rest of the codebase

Potential Issues 🟡

1. Misleading Header Name: The header is named Base44-State but based on the test values ('192.168.1.100', '10.0.0.50') and the commit message, it's actually used for client IP propagation. This naming mismatch could confuse future developers. Consider using a more descriptive name like Base44-Client-IP or documenting the purpose clearly.

2. Missing PR Description: The PR still lacks a description explaining the motivation and use cases.

Performance Considerations ✅

Minimal performance impact:

• Only creates the additionalHeaders object when the header is present
• No additional processing or validation overhead
• Efficient conditional logic

Security Concerns ⚠️

1. IP Spoofing Risk: The Base44-State header can be spoofed by clients. The implementation trusts the header value without validation. Consider:

   • Documenting that this header should only be trusted from known proxy/gateway sources
   • Adding IP address format validation
   • Warning users about security implications in documentation

2. No Input Validation: The header value is passed through without any validation. While this might be intentional for flexibility, consider validating it's a valid IP address format if that's the expected use case.

Test Coverage ✅

Excellent test coverage:

• Tests verify header propagation when present (tests/unit/client.test.js:223-241, 457-487)
• Tests confirm no header when absent (tests/unit/client.test.js:243-260, 489-516)
• Tests cover both user and service role scenarios (tests/unit/client.test.js:518-551)
• Integration tests with nock verify headers are passed correctly to API calls

Recommendations

1. Clarify Header Purpose: Either rename the header to better reflect its purpose (client IP propagation) or document why it's called Base44-State.

2. Add Documentation: Include JSDoc comments explaining:

   • The purpose of the Base44-State header
   • When to use it
   • Security considerations

3. Consider Validation: Add optional validation for the header value if it's meant to contain IP addresses:

   if (stateHeader && isValidIpAddress(stateHeader)) {
     additionalHeaders["Base44-State"] = stateHeader;
   }

4. Add PR Description: Explain the use case and why this feature is needed.

Overall, this is a well-implemented feature with good test coverage. The main concerns are around the misleading header name and the need for better documentation of the security implications.