You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
Some extra info: I tried to get the session ID by reading the PHPSESSID (or whatever session_name() returns) cookie, which actually seems to work. I tried doing it gracefully by injecting the '@request_stack' service so I could use the Request->cookie object, but the processor seems to receive an empty stack with no requests in it. All in all it seems the processor is called really early on when hardly anything seems to be bootstrapped. This kind of defies the purpose of the log processors, their main purpose being to enrich the log entries with metadata from the application.
This PR was merged into the 2.7 branch.
Discussion
----------
Fixed logger processor example
Fixes#7897.
Commits
-------
24ddb64 Fixed logger processor example
Uh oh!
There was an error while loading. Please reload this page.
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:
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 seemsSymfony\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 ofSession->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.
The text was updated successfully, but these errors were encountered: