theMiddle

same problem here.

just compiled now and @victorhora's patch works correctly. Thank you so much @zimmerle and @victorhora. Can this patch be merged to the master branch?

thanks! just an additional bit: before patching, I wasn't able to get any auditlog for each 403 response code from the upstream server (I mean even if the request didn't...

@victorhora @zimmerle after using the patched version of the nginx connector, I've a problem with a rule that I can't understand well. ``` SecRuleEngine On SecDefaultAction "phase:1,log,auditlog,deny,status:403" SecDefaultAction "phase:2,log,auditlog,deny,status:403" SecRule...

P.S. removing the rule: ``` # curl -v 'http://wordpress/?author=1' * Trying 127.0.0.1... * TCP_NODELAY set * Connected to wordpress (127.0.0.1) port 80 (#0) > GET /?author=1 HTTP/1.1 > Host: wordpress...

that's a tail from the nginx start to the request (error_log level debug): ``` 2020/02/18 14:24:12 [notice] 8#0: ModSecurity-nginx v1.0.1 (rules loaded inline/local/remote: 0/707/0) 2020/02/18 14:24:12 [notice] 8#0: using the...

I'm going to say something that will not help, but it seems something introduced with the recent commit related to the audit_log issue

in my setup, I always need to inform the user-agent about a block action (with a landing page that explain why it has been blocked)

@zimmerle ~~It's really strange that this problem occurs only with the rule I wrote above. With all other rules nginx replies with a 403~~. Anyway, I can't figure out at...

IIRC this was related to an old libmodsecurity bug (sort of https://github.com/SpiderLabs/ModSecurity/issues/2573) and now seems to be fixed. closing, feel free to reopen if needed