feat: Enable Transaction Service API key for local development

[LucieFaire]

Summary

COR-944
This branch adds support and documentation for using a Transaction Service API key during local development.

Changes

• Added an optional constructor parameter defaultHeaders?: Record<string, string> in FetchNetworkService to allow override of headers
• Added support for supplying a Transaction Service API key in local development so requests can include an Authorization: Bearer <apiKey> header when enabled.
• Added TxAuthNetworkModule that supplies a NetworkService pre-configured to attach Transaction Service auth headers (when enabled) so downstream modules can call the Transaction Service during local development.
• Added unit tests.
• Updated README with documented Tx API key usage

[LucieFaire]

@claude review

[claude]

Claude finished @LucieFaire's task —— View job

---

PR Review for Auth Header Implementation

Todo List:

• Examine configuration changes and environment setup
• Review new TxNetworkService implementation
• Analyze TxCacheFirstDataSource changes
• Check integration points in managers
• Review test coverage and quality
• Assess security implications of auth header handling
• Provide final feedback and recommendations

---

Issues to Address

Security Concerns

1. API Key Validation Missing - configuration.schema.ts:125

   • TX_SERVICE_API_KEY is optional but no runtime validation occurs before use
   • Consider adding validation that prevents empty strings or ensures proper format

2. Bearer Token Format - tx-auth.network.service.ts:74

   Authorization: `Bearer ${this.apiKey}`,

   • No validation that apiKey doesn't already contain "Bearer" prefix
   • Could result in malformed header like Bearer Bearer actualkey

Code Quality Issues

3. Inconsistent Logic Flow - tx-auth.network.service.ts:63

   if (!(this.isDevelopment && !this.useVpcUrl) || !this.apiKey) {
     return args;
   }

   • Complex boolean logic is hard to read and maintain
   • Consider breaking into separate conditions with clear comments

4. Duplicate Configuration - balances-api.manager.ts:48 vs transaction-api.manager.ts:34

   • Both inject TxNetworkService and TxCacheFirstDataSource
   • Creates inconsistency - balances should not need Tx-specific services unless it calls Transaction Service

Test Coverage Gaps

5. Missing Edge Cases - tx-auth.network.service.spec.ts

   • No test for empty string apiKey (only undefined)
   • No test for apiKey with existing "Bearer" prefix
   • No test for malformed/whitespace-only apiKey

6. Integration Test Missing

   • No end-to-end test verifying TxCacheFirstDataSource properly uses auth headers
   • Managers injecting TxNetworkService lack tests confirming auth behavior

Performance/Architecture

7. Service Injection Inconsistency - balances-api.manager.ts:47
   • BalancesApiManager injects TxNetworkService but doesn't need Transaction Service auth
   • Should use regular NetworkService unless balance endpoints require Tx Service auth
   • This creates unnecessary coupling and auth headers on non-Tx calls

Minor Issues

8. Missing Documentation
   • No inline docs explaining when auth headers are added
   • Configuration schema lacks description for TX_SERVICE_API_KEY usage

Recommendations

1. Fix BalancesApiManager injection - Use regular NetworkService unless balances specifically need Tx auth
2. Add apiKey validation - Check for empty/malformed keys before creating Bearer token
3. Simplify boolean logic - Break complex condition into readable parts with comments
4. Expand test coverage - Add edge cases for malformed API keys
5. Add integration test - Verify end-to-end auth header behavior

The implementation is solid overall but needs these security and consistency fixes before merging.

---

[tmjssz]

Have you verified the API key is never logged, including in error scenarios?

[LucieFaire]

Have you verified the API key is never logged, including in error scenarios?

hey, thank you for pointing that out. its a very valid concern. I have checked the logging in network service and caching, and headers, request body data and full request objects are NOT logged.

Yet the cache key includes all request options including headers (network.module.ts:134):

const key = JSON.stringify({ url, ...requestInit });
return hashSha1(key);

But:
The cache key is hashed using SHA1, so the Authorization header is not exposed
The cache key is only used internally and logged as a hash, not the raw stringified value
The cache logs only show the URL and the hashed key, never the request options

So there is no exposure of the auth header

[PooyaRaki]

I’ve reviewed the PR partially. Since there are major points that still need discussion, I’ll complete the rest of the review once we’ve reached a decision on those open items.

[PooyaRaki]

Nit: We could move it out of beforeEach since the initial value can be set once.

[PooyaRaki]

Nit: we should name it as FetchClient to be consistent.

[LucieFaire]

unfortunately, that creates confusion with FetchClient type, so I will keep it as-is