xrpl-py icon indicating copy to clipboard operation
xrpl-py copied to clipboard

Update CHANGELOG.md

Open joshuahamsa opened this issue 9 months ago • 3 comments

This change elevates support for custom HTTP headers to the base Client class, allowing all client implementations—HTTP and WebSocket—to access a shared headers attribute for authentication or metadata purposes.

• Updated the Client constructor to accept an optional headers argument. • The headers attribute is now accessible from all subclasses, enabling future support in WebSocket clients. • Maintains full backward compatibility with existing clients.

High Level Overview of Change

This PR introduces shared header support in the top-level Client class. The constructor now accepts an optional headers dictionary, which can be used to inject custom HTTP headers into XRPL client requests. This enables more flexible integration with infrastructure providers that require authentication tokens, API keys, or session-based headers.

The change ensures that any future client—including WebSocket-based ones—can leverage the same shared configuration without duplicating logic in subclasses like JsonRpcBase.

Context of Change

PR 763 would add header support only in JsonRpcBase, making it unavailable to other clients such as WebSocket-based ones. With XRPL infrastructure increasingly relying on authenticated access, this limitation restricted the usefulness of xrpl-py in production environments.

By moving headers to the abstract base class, this change unifies the configuration mechanism and enables consistent authentication handling across all clients.

Type of Change

[x] New feature (non-breaking change which adds functionality)

Did you update CHANGELOG.md? [x] Yes

Test Plan

The change can be tested by:

• Instantiating JsonRpcBase with a headers dictionary and verifying that headers are properly merged and included in JSON-RPC requests. • Creating a mock WebSocket client subclass that accesses self.headers and verifying shared availability. • Ensuring backward compatibility by initializing clients without the headers argument and observing unchanged behavior.

Future Tasks

Future tasks related to this change could include:

• Updating WebSocketClient to read from self.headers and send them during the handshake if supported. • Standardizing authentication strategies across all clients (e.g., Bearer tokens, session headers). • Adding test coverage for header usage across both sync and async clients.

joshuahamsa avatar Apr 10 '25 02:04 joshuahamsa