Context
When logging, values passed as part of the record context may contain PHP objects that are normalized by a Monolog\Formatter\FormatterInterface:
$logger->log(
'My message',
context: ['message' => $message, ...$additionalContext],
);
Problem
Consider an object like this:
final readonly class UpdateUser {
function __construct(
public string $id,``
#[SensitiveParameter]
public string $mySecretUrl,
) {}
}
Since PHP 8.2, #[SensitiveParameter] prevents UpdateUser::$mySecretUrl from appearing in stack traces. However, when such an object is passed as part of a log record context, this attribute is not respected and the sensitive value is still written to the logs.
Proposal
Formatters could leverage #[SensitiveParameter] to automatically redact sensitive properties during normalization.
Based on symfony/symfony#46183, this behaviour may not always be desired, so it could be implemented behind a configuration flag. That said, I would argue that redacting by default is the safer choice—frameworks like Symfony could then disable it in dev/debug mode if needed.
Additionally, since users often implement custom formatters, it would be helpful to expose this functionality in a reusable way.
Context
When logging, values passed as part of the record context may contain PHP objects that are normalized by a
Monolog\Formatter\FormatterInterface:Problem
Consider an object like this:
Since PHP 8.2,
#[SensitiveParameter]preventsUpdateUser::$mySecretUrlfrom appearing in stack traces. However, when such an object is passed as part of a log record context, this attribute is not respected and the sensitive value is still written to the logs.Proposal
Formatters could leverage
#[SensitiveParameter]to automatically redact sensitive properties during normalization.Based on symfony/symfony#46183, this behaviour may not always be desired, so it could be implemented behind a configuration flag. That said, I would argue that redacting by default is the safer choice—frameworks like Symfony could then disable it in dev/debug mode if needed.
Additionally, since users often implement custom formatters, it would be helpful to expose this functionality in a reusable way.