fix using relevant statuses + noauditlog

[AirisX]

No description provided.

[martinhsv]

Closing for the reasons in the related issue (incuding that this pull request would break DetectionOnly functionality).

[AirisX]

Hi @martinhsv ,
Why are you sure this PR would break DetectionOnly functionality? In my recent posts here #2637 I have provided example code that preserves this functionality:

if ((m_status == RelevantOnlyAuditLogStatus
        && this->isRelevant(transaction->m_httpCodeReturned) == false
        && transaction->getRuleEngineState() != static_cast<int>(RulesSetProperties::DetectionOnlyRuleEngine)) 
        || saveAnyway == false ) {

[martinhsv]

But that sample code is not part of this PR. This PR, as it stands, cannot be merged because it would break functionality.

You are welcome to submit a fresh pull request for consideration along the lines of what I described in #2637.

[AirisX]

I planned to include these lines after the discussion in # 2637. Ok, I'll open the new PR to include lines above

[877509395]

hi, Seems below command not supported by ModSecurity. Even if a small /file/path/file-name  curl -F "filename=@/file/path/file-name"  www.test5.com modsecurity create two transactions for this request, I think it should not, it should be one request one transaction.  mod version: 3.0.6 mod-nginx-connector: 1.0.2 core-rule-set: 3.4.0 Below json will be triggerred.    {     "source":"modsecurity",     "type":"attack",     "mId":"104617fcd945_172.18.0.2",     "client_ip":"172.18.0.1",     "time_stamp":"Tue Dec 21 10:42:54 2021",     "server_id":"cc57a40222759adedd87fbb5e0f450fd4d103a60",     "version":"commit 85b176b5e39d513985e3455f908688e525bfe061",     "client_port":58302,     "host_ip":"172.18.0.2",     "host_port":80,     "unique_id":"1640083374",     "http_version":1.1,     "uri":"/",     "http_code":403,     "server_name":"www.test5.com",     "method":"GET",     "request":{         "body":"",         "headers":{             "Host":"www.test5.com",             "User-Agent":"curl/7.80.0",             "Accept":"*/*",             "Content-Length":"348",             "Content-Type":"multipart/form-data; boundary=------------------------34484de1b7a90294"         }     },     "response":{         "body":"",         "http_code":403,         "headers":{         }     },     "messages":[         {             "attackName":"GET or HEAD Request with Body Content",             "details":{                 "match":"Matched \"Operator `Rx' with parameter `^0?$' against variable `REQUEST_HEADERS:Content-Length' (Value: `348' )",                 "reference":"o0,3v0,3v87,3",                 "ruleId":"920170",                 "data":"348",                 "severity":"2",                 "action":"block and log",                 "attackClass":"PROTOCOL"             }         }     ] } huiming Message ID: ***@***.***>

[martinhsv]

Hello @877509395 ,

I would encourage you to not post unrelated content into PRs or issues. Since such issues and PRs persist, it's helpful if each PR or issue only contains postings relevant to it.

Regarding your assertion, if you think you have identified some anomaly certainly feel free to open an issue for it. In this case, however, I would suggest more investigation on your part would be in order. You state that 'modsecurity create two transactions for this request'. That is unlikely. If a second transaction is being processed, it is much more likely that it is being created some other way such as through nginx configuration that includes error redirects. See for example owasp-modsecurity/ModSecurity-nginx#152 (comment)