fix: admin keys showing as [object Object] in security config UI

[Yeraze]

Summary

Remote Admin keys on the Device Configuration page displayed as [object Object] instead of base64 strings, on both SQLite and PostgreSQL backends.

Root cause: Protobuf bytes fields serialize to plain objects with numeric keys when JSON-encoded (e.g., {"0": 72, "1": 101, ...}). Both server and frontend key conversion code only handled Uint8Array, Buffer, and plain arrays — not these generic objects, so they fell through to String(key) which produced [object Object].

Fix:

• Server: extracted shared bytesToBase64() helper with generic object fallback via Object.values()
• Frontend: added same Object.values() conversion for generic byte objects in ConfigurationTab.tsx

Changes

File	Change
src/server/server.ts	bytesToBase64() helper, replaced inline conversion in both local and remote config paths
src/components/ConfigurationTab.tsx	Added generic object→base64 conversion for admin keys

Test plan

• npx vitest run — 3070 tests pass
• npm run build — no TypeScript errors
• Deploy on SQLite, verify admin keys display correctly
• Verify on PostgreSQL backend

🤖 Generated with Claude Code

[github-actions]

Claude finished @Yeraze's task —— View job

---

Code Review Feedback

Summary: This PR effectively fixes the "[object Object]" display issue for admin keys by properly handling protobuf byte serialization. The implementation is solid with good error handling and consistent patterns across both server and frontend.

Todo List

• Read and analyze modified files
• Review code quality and best practices
• Check for potential bugs or edge cases
• Assess performance considerations
• Evaluate security concerns
• Analyze test coverage
• Provide comprehensive feedback

✅ Code Quality & Best Practices

Server Changes (src/server/server.ts:211-234):

• Excellent: Extracted bytesToBase64() helper function eliminates code duplication between local and remote config paths
• Good type handling: Comprehensive coverage of different byte formats (Uint8Array, Buffer, arrays, objects)
• Proper fallbacks: Graceful degradation with warning log and empty string return
• Clean documentation: Clear JSDoc comment explaining purpose

Frontend Changes (src/components/ConfigurationTab.tsx:712-718):

• Consistent approach: Mirrors server-side logic with Object.values() conversion
• Good error handling: Try-catch block prevents crashes on malformed data
• Proper fallback: Returns empty string when conversion fails

✅ Bug Analysis

Root cause correctly identified: Protobuf bytes fields serialize to {"0": 72, "1": 101, ...} objects, which existing code couldn't handle.

Fix addresses the issue: Both server and frontend now handle these generic objects via Object.values() conversion.

Edge cases handled:

• Empty/null keys
• Malformed objects (try-catch protection)
• Mixed key formats in arrays
• String keys (already base64)

✅ Performance Considerations

Minimal impact:

• Object.values() is O(n) where n = key length (typically 32 bytes)
• Only runs when keys are present and need conversion
• No unnecessary allocations or complex operations

Efficient approach:

• Early returns for common cases (Uint8Array, Buffer, strings)
• Generic object handling as last resort

⚠️ Minor Security Considerations

Type safety: Using any types for key parameters, but this is appropriate given the diverse input formats from protobuf serialization.

Input validation: The code handles malformed input gracefully without crashes or security issues.

Logging concern: logger.warn('Unknown admin key format:', typeof key, key) at server.ts:232 could potentially log sensitive data. Consider logging only the type and length:

logger.warn('Unknown admin key format:', typeof key, Array.isArray(key) ? `array[${key.length}]` : 'object');

✅ Test Coverage

Based on PR description:

• ✅ 3070 tests pass
• ✅ TypeScript compilation succeeds
• ✅ Manual SQLite testing completed
• ⏳ PostgreSQL testing pending

Recommendation: The fix should work identically across all database backends since the issue is in protobuf serialization, not database-specific code.

Overall Assessment

🟢 Excellent fix - Clean, comprehensive solution that:

• Correctly identifies and fixes the root cause
• Maintains code consistency between server and frontend
• Includes proper error handling and fallbacks
• Eliminates code duplication through helper extraction
• Has minimal performance impact

Minor suggestion: Consider sanitizing the logging statement to avoid potential sensitive data exposure.

Ready for merge ✅