Include HTTP request's headers in the log entry
arggh opened this issue · comments
In the scenario where a log entry is added from the client via HTTP, it would be nice to include the request's headers in the logs, parsed or raw (easy). This way, if properly configured, the IP (amongst other things) would be included and available for logging.
Difficult: the information the client has about its own IP is typically irrelevant as it will most of the time be a NAT address on the local LAN.
The server-side could conceivably log the IP whence the client log request originates, probably in handleClientLogRequest() or a processor. Note that to get near any level of reliability, though, this needs some configuration which is a bit advanced, like handling a chain of proxies with varying headers e.g. Akamai CDN with RealIP headers, then a Nginx or Apache cluster to drop https, then a Varnish cluster for the actual cached reverse-proxying. We have this type of logic in Drupal 7 ip_address() and Drupal 8/Symfony HttpFoundation in Request::getClientIP() and even these convoluted configurable functions fail to cover most production configurations I've had to work with.
Do you know any reliable NPM package we could wrap for this ?
Sorry for opening a confusing issue: I started digging into the internals of FiLog and soon realized the IP address information I was talking about in my logs was added by me (originating from Accounts.onLogin).
So, to re-phrase the opening message of this issue...
In the scenario where a log entry is added from the client via HTTP, it would be nice to include the request's headers in the logs, parsed or raw (easy). This way, if properly configured, the IP (amongst other things) would be included and available for logging.
I think this could be done by adding a new boolean logRequest to the parameters in ServerLogger constructor, and in the end callback within handleClientLogRequest add a request key to the context before the call to objectifyContext. That would avoid adding it when not needed, allow adding it if needed, and preserve compatibility. Think that would be good ?
Sounds good to me!
Small change: I did it after objectifyContext to avoid bumping into ill-formed context values. It's not a default. I'll add some tests later today.
Could not find a way to write the needed automated tests, so only tested manually. Merged.