Caddy handle_errors not working with v2

[skixmix]

Hello,

Whilst working with the most recent version (v2) of this module, I observed that the handle_errors directive is no longer functional with the 403 code initiated by the WAF. However, in the v1.2.2 version of the module, this feature operates correctly.

My configuration (the commented parts are used in v2):

	# Error handling
	handle_errors {
		reverse_proxy http://localhost:5001 {
			respond "Hello"
		}
	}


        coraza_waf {
			# load_owasp_crs
			# directives `
			include /waf/coraza/coraza.conf-recommended
			include /waf/coreruleset/crs-setup.conf.example
			include /waf/coreruleset/rules/*.conf
			# `
        }

In version 1.2.2, the activation of a rule prompts the display of the "Hello" message. However, in version 2, the standard browser's 403 page is presented instead.

Thank you,
Simone

[jptosso]

@jcchavezs I can confirm it used to work, but something changed in how we handle errors. @jcchavezs @M4tteoP

[M4tteoP]

Am I wrong to say that this issue can be closed? #164 added handle_errors to the example and to the readme 🤔

[BurningDog]

I wasn't able to get handle_errors working following the example (tried both options). Caddy v2.8.4 and Coraza github.com/corazawaf/coraza-caddy@master

This may be because instead of putting coraza_waf and handle_errors inside :8080 { as per the example I'm using route { following an older version of the API Platform config - getting this error:

Error: adapting config using caddyfile: parsing caddyfile tokens for 'route': handle_errors directive returned something other than an HTTP route or subroute:

The newer version specifies {$SERVER_NAME:localhost} { instead of route {

Caddy accepts this, however when requesting /admin I get the expected 403 response but no expected HTML response body or X-Blocked header.

[github-actions]

This issue has been open 30 days waiting for feedback. Remove the stale label or comment, or this will be closed in 14 days.