webthatmatters / laravel-request-overseer
A laravel package for logging request/response data.
Installs: 538
Dependents: 1
Suggesters: 0
Security: 0
pkg:composer/webthatmatters/laravel-request-overseer
Requires
- ext-json: *
Requires (Dev)
- mockery/mockery: ^1.2
- orchestra/database: ^3.4
- orchestra/testbench: ^3.4
- phpunit/phpunit: ^5
Suggests
- jenssegers/mongodb: Needed for mongodb connections
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\OverseerServiceProviderto yourconfig/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, runphp artisan migrateto create the logs table - Add
WebThatMatters\Overseer\Middleware\LogMiddlewareto therouteMiddlewarein yourApp\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 defaultenv('DB_CONNECTION', 'mysql'). Be sure to have this configured properlyrequest_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 useAuth::id()to determine the user, so make sure you have authentication guards configured properly. Defaults to truelog_request_body: Whether to log the request body. Defaults to truelog_response_body: Whether to log the response body. Defaults to truetable: The name of the table to use for the logs, defaults torequest_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\LogEntryRepositoryto 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\LogEntryProcessorto 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.