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
So, the next time the same ruleId is used, it doesn't do anything but links to the existing rule and message. So, the 1st ruleMsg logged is the one that applies to that rule forever.
The problem with this is that some ruleMsg text changes per call, such as the inclusion of the source IP address e.g. Denial of Service (DoS) Attack Identified from x.x.x.x (y hits since last alert).
We can't do INSERT ... ON DUPLICATE KEY UPDATE because then the latest message will always be the one shown then.
The text was updated successfully, but these errors were encountered:
When a rule_message is logged it uses the following SQL:
$sql_ruleMessage = 'INSERT IGNORE INTO
rule_message(
message_ruleId,
message_ruleMsg) VALUES (:MessageRuleId2, :MessageMsg)';
So, the next time the same ruleId is used, it doesn't do anything but links to the existing rule and message. So, the 1st ruleMsg logged is the one that applies to that rule forever.
The problem with this is that some ruleMsg text changes per call, such as the inclusion of the source IP address e.g. Denial of Service (DoS) Attack Identified from x.x.x.x (y hits since last alert).
We can't do
INSERT ... ON DUPLICATE KEY UPDATE
because then the latest message will always be the one shown then.The text was updated successfully, but these errors were encountered: