Skip to content

Resolve client IP from the socket peer address as a fallback#193

Closed
bartes wants to merge 1 commit into
masterfrom
feat/ip-fallback-socket-remote-address
Closed

Resolve client IP from the socket peer address as a fallback#193
bartes wants to merge 1 commit into
masterfrom
feat/ip-fallback-socket-remote-address

Conversation

@bartes
Copy link
Copy Markdown
Contributor

@bartes bartes commented Jun 5, 2026

The client IP is now resolved from the connection's peer address when no X-Forwarded-For or Remote-Addr header is present, so direct and localhost requests carry a context.ip instead of none.

Changes

  • IPsExtractService.call accepts an optional remoteAddress and surfaces it as remote-addr only when that header is absent. It participates in extraction with the existing precedence (after X-Forwarded-For), trusted-proxy filtering, trustedProxyDepth, and trustProxyChain. An existing remote-addr header is preserved, and custom ipHeaders that exclude remote-addr ignore it.
  • ContextGetDefaultService derives the value from the request connection across frameworks: socket.remoteAddress, then connection.remoteAddress, then info.remoteAddress (raw Node IncomingMessage, Express, Fastify, Koa, Next, Hapi).
  • Added a shared CastleRequest type for the request shape consumed by the context services.
  • README documents the socket fallback under Client IP detection.

The third IPsExtractService.call argument is optional and the fallback only applies when no IP header yields a value, so existing behavior is unchanged.

The IP extractor now accepts an optional remote address and surfaces it as
`remote-addr` when no `x-forwarded-for` or `remote-addr` header is present, so
extraction precedence, trusted-proxy filtering, and custom `ipHeaders` are
unchanged. The default context derives this value from the request connection
(`socket.remoteAddress`, `connection.remoteAddress`, or `info.remoteAddress`),
covering the raw Node `IncomingMessage`, Express, Fastify, Koa, Next, and Hapi.
A shared `CastleRequest` type describes the request shape consumed by the
context services.
@bartes
Copy link
Copy Markdown
Contributor Author

bartes commented Jun 5, 2026

Closing for now — the localhost case is handled in the example app instead. Keeping the branch around in case we revisit SDK-level autodetection.

@bartes bartes closed this Jun 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant