chore: add client headers

[shrimalmadhur]

Motivation:

Modifications:

Add client header to user api endpoints

Result:

Testing:

Open questions:

[claude]

Claude finished @shrimalmadhur's task —— View job

---

PR Review: Add Client Headers

Review Checklist:

• Read repository guidelines (CLAUDE.md)
• Analyze changed files and understand modifications
• Review code quality and best practices
• Check for potential bugs or issues
• Evaluate security concerns
• Assess performance implications
• Check test coverage
• Provide comprehensive feedback

---

Summary

This PR adds x-client-id headers to user API endpoints and TLS keygen operations to identify client applications. The changes are minimal and focused on header identification.

Code Quality & Best Practices ✅

Positive aspects:

• Consistent implementation: The x-client-id header is added consistently across both TLS keygen and user API clients
• Proper versioning: Uses dynamic version from version.GetVersion() for the CLI client
• Good separation: Each client uses appropriate identification ("tls-keygen" vs "eigenx-cli/version")
• Minor bug fix: Fixed error message in info.go from "failed to get KMS client" to "failed to get userApi client"

Potential Issues & Suggestions

1. Missing Import Declaration 🔴

In pkg/commands/utils/userapi_client.go:13, the new import for "github.com/Layr-Labs/eigenx-cli/internal/version" is added but should be grouped with other internal imports for better organization.

2. Error Handling ⚠️

What happens if version.GetVersion() returns an empty string or fails? Consider adding fallback:

clientID := fmt.Sprintf("eigenx-cli/%s", version.GetVersion())
if version.GetVersion() == "" {
    clientID = "eigenx-cli/unknown"
}

3. Header Naming Convention ℹ️

The use of x-client-id follows the X- prefix convention for custom headers. However, RFC 6648 discourages this. Consider using just client-id for new headers, though changing existing ones may break compatibility.

Security Considerations ✅

• No sensitive data exposure: The headers only contain client identification, no secrets
• Version information: While version info could be used for fingerprinting, it's useful for debugging and analytics

Performance Implications ✅

• Minimal overhead: Adding headers has negligible performance impact
• No additional network calls: Headers are part of existing requests

Test Coverage ⚠️

Missing tests for:

• New header presence in requests
• Version information formatting
• Client ID values for different clients

Recommendations:

• Add unit tests verifying the x-client-id header is set correctly
• Test version string formatting in client ID
• Verify TLS keygen includes the static "tls-keygen" identifier

Binary Changes 📋

The tools/tls-keygen-linux-amd64 binary was updated, presumably to include the new header functionality. This is expected given the changes to the TLS keygen source code.

Overall Assessment

This is a clean, focused PR that adds valuable client identification to API requests. The implementation is consistent and follows good practices. The main concerns are around test coverage and minor error handling improvements.

Recommendation: ✅ Approve with minor suggestions

The changes are low-risk and provide value for API request tracking and debugging. Consider adding the suggested error handling and tests in a follow-up.

---