Description
To illustrate what you can do with log processors, there's a code example in logging/processors.rst which adds a token to the log entry based on the session ID. This allows the administrator to match different log entries, possibly even in different log files, to a single request, or even multiple requests in one session:
namespace AppBundle;
use Symfony\Component\HttpFoundation\Session\Session;
class SessionRequestProcessor
{
private $session;
private $token;
public function __construct(Session $session)
{
$this->session = $session;
}
public function processRecord(array $record)
{
if (null === $this->token) {
try {
$this->token = substr($this->session->getId(), 0, 8);
} catch (\RuntimeException $e) {
$this->token = '????????';
}
$this->token .= '-' . substr(uniqid(), -8);
}
$record['extra']['token'] = $this->token;
return $record;
}
}The processor adds a 'token' value to the 'extra' part of the log record. The token is comprised of the first 8 characters from the session ID, and another 8 random hexadecimal characters. If there's no started session (which is tested by catching any exception caused by $this->session->getId(). Should this throw an exception, the session ID part will be replaced by '????????'.
So, the expected result would be a token like abcd1234-def567889 for a request with a started session, and ????????-abcd1234 for a request with no started session.
However, it seems that, regardless the session state, the first part of the token is blank, resulting in tokens like -abcd1234. It seems Symfony\Component\HttpFoundation\Session\Session->getId() simply returns an empty string if the session has not been started yet. So there's no exception to be caught. This could be solved by checking if the result of Session->getId() is empty instead of trying to catch an exception. This leads us to the next issue: the session is never started when the log processor is called. Even for requests which require authentication (ie. a started session is required), the session ID part is blank.
One could start the session from the processor, this actually gives us the desired results; log entries have a token which allows us to distinguish the session and specific request the entry belongs to. However, this is a very, very dirty hack and leads to undesired side effects. In our case, all our behat tests started to fail.
Either this simply does not work anymore (I can't tell whether it had worked at some point) because the processors are being called too early on, or it could still work with some alterations. Either way, I think this page needs some attention.