webthatmatters/laravel-request-overseer

This package is abandoned and no longer maintained. No replacement package was suggested.

A laravel package for logging request/response data.

1.3.3 2019-09-20 15:13 UTC

This package is auto-updated.

Last update: 2022-11-11 15:36:07 UTC


README

A package for easy and configurable request logging.

Features

  • Log all request data, including headers and (optionally) current user
  • Log response status, headers and (optionally) body
  • Configurable connection, supporting both MongoDB and any database Eloquent supports

Installation

  • Install package using composer require webthatmatters/laravel-request-overseer
  • Add WebThatMatters\Overseer\Providers\OverseerServiceProvider to your config/app.php's providers
  • Run php artisan vendor:publish --provider="WebThatMatters\Overseer\Providers\OverseerServiceProvider" --tag=config, to publish the package configuration if you wish to modify it
  • Run php artisan vendor:publish --provider="WebThatMatters\Overseer\Providers\OverseerServiceProvider" --tag=migrations, in order to publish the package migrations
  • If using a connection other than mongodb, run php artisan migrate to create the logs table
  • Add WebThatMatters\Overseer\Middleware\LogMiddleware to the routeMiddleware in your App\Http\Kernel, using any name you want
  • Use the registered middleware in your routes
  • Profit!

Configuration

The following keys are included in overseer.php and can be changed once you publish the configuration.

  • connection : The laravel connection name to use, by default env('DB_CONNECTION', 'mysql'). Be sure to have this configured properly
  • request_headers : Which request headers to log, as an array of strings. By default this is set to '*', meaning all headers.
  • response_headers : Which response headers to log, as an array of strings. By default this is set to '*', meaning all headers.
  • log_user: Whether to log the current request's user. This will use Auth::id() to determine the user, so make sure you have authentication guards configured properly. Defaults to true
  • log_request_body : Whether to log the request body. Defaults to true
  • log_response_body : Whether to log the response body. Defaults to true
  • table : The name of the table to use for the logs, defaults to request_logs. When using MongoDB, this is the collection name to use.

NOTE When logging request/response bodies, be sure your database's text type can handle the maximum size you expect your data to be.

Extension

  • In order to provide a different persistence layer, you can bind your implementation of WebThatMatters\Overseer\Repositories\LogEntryRepository to the container instead of the default one, and persist the log entry as you see fit.
  • If you wish to process the request lifecycle entry log differently, you can bind your implementation of WebThatMatters\Overseer\Processing\LogEntryProcessor to the container. However, this would require you to implement the configuration behaviour if you wish to keep it.

Filters

This package provides a custom request filtering functionality, so you can only log requests that fulfill certain criteria. In order to use the filtering feature, you need to register your filters in a FilterRegistry. By default, an empty registry is bound to the container. If you wish to register filters, you can bind a new instance of the registry to the container in one of your providers:

<?php
    use WebThatMatters\Overseer\Filters\FilterRegistry;
    use WebThatMatters\Overseer\Filters\MethodTypeFilter;
    
    $registry = new FilterRegistry();
    $registry->register('modify',new MethodTypeFilter(['PUT','POST','DELETE']));
    $this->app->instance(FilterRegistry::class,$registry);

You can then use any registered filter in routes or route groups by using its registered name as a parameter to the provided middleware:

<?php
use Illuminate\Support\Facades\Route;
Route::group(['middleware' => 'log:modify'],function(){
    // Your routes here
});

The package ships with a few filters ready to use, but you can also implement your own by implementing the Filter interface. The provided filters are:

  • MethodTypeFilter : A filter that filters requests based on their method types. The allowed method types are passed as an array of strings in the constructor.
  • AndFilter: A composite filter that applies if both the first and the second filter provided in the constructor apply.
  • OrFilter: A composite filter that applies if either the first or the second filter provided in the constructor apply.