Skip to main content

resolve_with_peer

parse_rust_server::auth

Function resolve_with_peer 

Source 
pub fn resolve_with_peer(
    config: &ServerConfig,
    headers: &HeaderMap,
    peer: Peer,
) -> Result<Authority, HeaderRejection>
Expand description

Resolve authority from headers and the peer address.

Upstream ordering that matters:

  1. The appId must match, else invalidRequest.
  2. Master or maintenance short-circuits, returning before client-key validation (middlewares.js:249-251). A request carrying both a master key and a session token is a master request, and the token is not resolved.
  3. Otherwise, if any client key is configured, one must match.

The peer address is the socket’s, never a header’s. Upstream’s getClientIp is req.ip (middlewares.js:358-360), and Express resolves that from the connection unless trust proxy is set, which parse-server does not set. An allowlist that reads X-Forwarded-For is not an allowlist, because the caller writes it. A deployment behind a load balancer therefore sees every request as coming from the balancer and must widen the option; that is an availability failure rather than an authorization one, and it is the correct direction to fail in until trusted-proxy configuration exists.

A matching master key from a non-allowlisted address is refused, not demoted to a client request. Upstream throws (middlewares.js:453-462) rather than falling through, so a caller cannot use a rejected master key to skip client-key validation.