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
According to legacy handbook for modsecurity 2.x, debug log line included some useful data [1]:
The line starts with metadata that is often longer than the message itself: the time, client’s IP address, internal server ID, internal request ID, request URI, and finally, the debug log level. The rest of the line is occupied by the message, which is essentially free-form.
In case of libmodsecurity, every debug log line starts from log level digit, there are no timestamps, request IDs, URIs, etc.
It would be great to have all these details for easier debugging.
In case of request ID, it also would be really nice to have an ability to obtain it from the initiating connector (e.g., nginx has $request_id variable that could be used in libmodsecurity logs as well as in nginx access logs, bringing a bit more transparency for those who're digging in large amount of logs).
There is a clear value to stamp the transaction ID and the request uri, as it should facilitate the life of our users. The idea to share within the connector is something really great.
As of 4dd2812 the API has a new method that allows a transaction to be created with a given ID instead of a random-generated one. The msc_new_transaction_with_id is not yet in use by the ngnix connector, but we get there :)
The debug logs contains the ID and the URI since: c721e10.
According to legacy handbook for modsecurity 2.x, debug log line included some useful data [1]:
In case of libmodsecurity, every debug log line starts from log level digit, there are no timestamps, request IDs, URIs, etc.
It would be great to have all these details for easier debugging.
In case of request ID, it also would be really nice to have an ability to obtain it from the initiating connector (e.g., nginx has
$request_id
variable that could be used in libmodsecurity logs as well as in nginx access logs, bringing a bit more transparency for those who're digging in large amount of logs).[1] https://www.feistyduck.com/library/modsecurity-handbook-free/online/ch04-logging.html
The text was updated successfully, but these errors were encountered: