Download the PHP package garbetjie/http-request-logger without Composer

HTTP Request Logger

An HTTP request logging library that makes it simple to easy to implement the logging of all HTTP requests & responses.

Works with Laravel, Guzzle and PHP's SoapServer and SoapClient classes.

Table of contents

• Introduction
• Installation
• Usage
  • Incoming requests: Laravel
  • Incoming requests: PSR-15 compliant frameworks
  • Incoming requests: SOAP server
  • Outgoing requests: Laravel
  • Outgoing requests: Guzzle
  • Outgoing requests: SOAP
• Customisation
  • Context
  • Request & response IDs
  • Toggling logging
• Changelog

Introduction

It is often quite useful to be able to see all requests & responses generated by your application - especially whilst in development. This library makes it trivial to log all incoming & outgoing requests & responses using Monolog.

By default, all requests & responses are logged at the debug log level. Sensible defaults for logging context are used, and headers that may contain sensitive values (such as Cookie, Set-Cookie and Authorization) have their values obfuscated. Each request & corresponding response are linked together through a unique ID. This allows you to interrogate your logs to find the matching response for any given request.

Installation

Usage

Incoming requests in Laravel

Enabling request logging in Laravel is as simple as adding the middleware to the $middleware property on your App\Http\Kernel class. The example shown below is enough to ensure that all incoming requests & outgoing responses are logged in Laravel:

Take note: You should add the request logging middleware to your application's global middleware stack, and determine when logging should take place in a service provider. When added to a middleware group, any uncaught exceptions thrown will prevent the request & response from being logged.

See the Toggle enabled/disabled section for more information on this.

Incoming requests in PSR-15 compliant frameworks

If you are not using Laravel, but are making use of a framework that adheres to PSR-15, you'll need to be a little more explicit in creating the middleware. The example below makes use of the Slim framework as an example:

Incoming SOAP requests

Logging incoming SOAP requests is trivial. Instead of creating a new \SoapServer instance, simply create a new instance of \Garbetjie\RequestLogging\Http\SoapServer. You can use this new instance exactly the same as you would with an instance of \SoapServer. Example shown below:

Outgoing requests in Laravel

WHen using Laravel, you can simply type-hint either GuzzleHttp\ClientInterface or GuzzleHttp\Client wherever Laravel performs dependency injection. This package includes a service provider that automatically adds the middleware to a handler stack for you.

An example of using this type-hinting in a controller is shown below:

Outgoing requests through Guzzle

Outbound request logging happens through Guzzle middleware. In order to log outbound requests, simply add an instance of the OutgoingRequestLoggingMiddleware to your handler stack. Ideally, this should be the last middleware in your handler stack in order to ensure the logged representation of the request is as accurate as possible.

Outgoing SOAP requests

In order to log outbound SOAP requests, simply create your Guzzle client as if you be logging any other outgoing HTTP request, and pass this client instance to a new instance of Garbetjie\RequestLogging\Http\SoapClient. You can use this SOAP client instance just as if you were making use of a native SoapClient instance:

Customisation

All aspects of the request & response logging are customisable. This includes the ID used to link a request & response together, the log message, as well as the context logged with each request & response.

Logging context

By default, incoming & outgoing requests generate a context with a similar structure to below. Sensitive headers such as Authorization and Cookie have their values replaced with ***:

The context shown below indicates the default structure of the logging context for responses. Any Set-Cookie headers have their values stripped out and replaced with ***.

It is quite simple to customise the logging context that is generated:

If you'd like to simply extend off the context that is created by default, you can reuse the context extractors that are already available:

ID generation.

By default, the ID generation for linking requests & responses together makes use of endyjasmi/cuid to generate a full CUID.

This can be easily customised by providing a callable that simply returns a string containing the ID to use:

Toggling logging

By default, all requests & responses are logged. However, it is possible to toggle whether a request or response should be logged. Simply provide either a boolean value, or a callable that returns a boolean value indicating whether or not logging should be enabled for the given request:

Changelog

See CHANGELOG.md for the full changelog.