Logging actual client IP address instead of network address of reverse proxy

[SimonFrings]

When using the built-in web server and taking a look into the access log, you'll notice that every incoming IP address is listed as 127.0.0.1, which is the network address of the reverse proxy. This information is not very meaningful, so it would make sense to identify the originating IP address of a client.

This could be done by adjusting a used middleware (e.g. the AccessLogHandler, see #169) or by using a trusted proxy mechanism. See also X-Forwarded-For (XFF) request header.

These are some of the ideas on our end, we're happy to hear about your opinion! 👍

[pfk84]

My vote: XFF should be sufficient in most cases and therefore already is a big and quick improvement over the current situation.

[clue]

Agree that the X-Forwarded-For (XFF) request header is the de-facto standard at the moment, but there's also the relatively new standard Forwarded request header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded

Right now, X does not have any special logic for either header, but allows you to build custom middleware to apply custom logic as suggested in the other reply in this discussion: #172 (comment)

I'm currently not sure how much support for either header needs to be built into X, but I can definitely see use cases for both headers also longer-term. Personally, I would rather promote the standard Forwarded header if supported by the environment X is deployed to.

[clue]

Small progress update 1 now that PRs #173 and #174 have been merged 🎉 You may now pass a custom middleware to change the REMOTE_ADDR server param before forwarding the request to the AccessLogHandler like this:

<?php

require __DIR__ . '/../vendor/autoload.php';

class TrustedProxyMiddleware
{
    public function __invoke(Psr\Http\Message\ServerRequestInterface $request, callable $next)
    {
        $params = $request->getServerParams();
        if (($params['REMOTE_ADDR'] ?? null) === '127.0.0.1' && $request->hasHeader('X-Forwarded-For')) {
            $params['REMOTE_ADDR'] = preg_replace('/,.*/', '', $request->getHeaderLine('X-Forwarded-For'));
            $request = (new React\Http\Message\ServerRequest(
                $request->getMethod(),
                $request->getUri(),
                $request->getHeaders(),
                $request->getBody(),
                $request->getProtocolVersion(),
                $params
            ))->withRequestTarget($request->getRequestTarget())->withCookieParams($request->getCookieParams())->withParsedBody($request->getParsedBody())->withUploadedFiles($request->getUploadedFiles());
        }

        return $next($request);
    }
}

$app = new FrameworkX\App(
    TrustedProxyMiddleware::class,
    new FrameworkX\AccessLogHandler(),
    new FrameworkX\ErrorHandler()
);

// Register routes here, see routing…

$app->run();

This example uses 127.0.0.1 as a trusted proxy and assumes the X-Forwarded-For (XFF) request header passed by the upstream proxy can be trusted.

Unfortunately PSR-7 does not define a withServerParams() method, so the above code has to create a whole new ServerRequest object and has to manually copy over all values from the original request.

This is a starting point to add more options to control this behavior in follow-up PRs as discussed here.

[clue]

Small progress update 2 now that PRs #177 and #175 have been merged 🎉 You may now pass a custom middleware to change the $remote_addr attribute before forwarding the request to the AccessLogHandler like this:

<?php

require __DIR__ . '/../vendor/autoload.php';

class TrustedProxyMiddleware
{
    public function __invoke(Psr\Http\Message\ServerRequestInterface $request, callable $next)
    {
        // use 127.0.0.1 as trusted proxy to read from X-Forwarded-For (XFF)
        $remote_addr = $request->getAttribute('remote_addr') ?? $request->getServerParams()['REMOTE_ADDR'] ?? null;
        if ($remote_addr === '127.0.0.1' && $request->hasHeader('X-Forwarded-For')) {
            $remote_addr = preg_replace('/,.*/', '', $request->getHeaderLine('X-Forwarded-For'));
            $request = $request->withAttribute('remote_addr', $remote_addr);
        }
        return $next($request);
    }
}

$app = new FrameworkX\App(
    TrustedProxyMiddleware::class,
    FrameworkX\AccessLogHandler::class,
    FrameworkX\ErrorHandler::class
);

// Register routes here, see routing…

$app->run();

This example uses 127.0.0.1 as a trusted proxy and assumes the X-Forwarded-For (XFF) request header passed by the upstream proxy can be trusted.

This is a next step to add more options to control this behavior in follow-up PRs as discussed here.