When an exception occurs in a web request, the Flare client will pass on all request fields that are present in the body.
In some cases, such as a login page, these request fields may contain a password that you don't want to send to Flare. By default, Flare will replace the value any fields that are named "password" with "<CENSORED>".
You can censor values of additional fields. If you use Laravel, you can put the names of those fields in the reporting.censor_request_body_fields key of the flare config file.
// config/flare.php
return [
// ...
'reporting' => [
// ...
'censor_request_body_fields' => ['password', 'other_field'],
]
]
In non-Laravel PHP projects you can use call censorRequestBodyFields on the Flare client. You should pass it the names of the fields you wish to censor.
// Where you registered your client...
$flare = Flare::register('YOUR-FLARE-API-KEY')
->registerFlareHandlers();
$flare->censorRequestBodyFields('password');
This will replace the value of any sent fields named "password" with the value "<CENSORED>".
You can see other improvements we recently made on our changelog. Do you have an idea to improve Flare? Let us know!
Continue reading
One core, many clients: the new Flare JavaScript client architecture
We recently reshaped the Flare JavaScript client from a single browser library and a few thin framework specific packages into a small family of packages built on a shared, platform-agnostic core. This post explains why we did it, what the core package exposes, how the browser and Node SDKs are built on top of it, why the React, Vue, and Svelte packages sit one level higher, and how anyone can use the same core to write a Flare JS client for a platform we do not ship ourselves.
Dries
Logging is here!
Logging is now available for all Flare users! Send any log from your app to Flare and use our polished interface to filter and search your logs in real-time.
Jimi
Subscribe to Backtrace, our quarterly Flare newsletter
No spam, just news & product updates