Custom error pages (and captcha support)

[Simbiat]

My config has custom error pages, but looks like they are not being applied if access is blocked by CrowdSec (they do get applied if it's done by Coraza, though). Instead I am seeing generic Caddy's page (not the one from CrowdSec either). Furthermore if I block IP with "captcha" instead of "ban" I am still getting 403 error, instead of expected 401. Is this some limitation of the plugin or am I doing something wrong?

[LaurenceJJones]

Seems captcha is a TODO:

https://github.com/hslatman/caddy-crowdsec-bouncer/blob/6022901f3397e5fe5d01f744a23986754746eabe/http/http.go#L127-L130

There is no custom pages, so this needs to be implemented also as since crowdsec directive acts as a middleware it stops the chaining input. I dont know how the coraza implementation works to get around this.

[hslatman]

That's quite the config, @Simbiat 😛

Yes, captcha has been on my list for a while now. Also see my not-so-strict TODO list. Main thing to decide is what technology to use, as I don't want to force people to use reCaptcha, for example. Ideally I would like to make it pluggable.

Without looking much deeper into the code, I think this might be what makes the error pages work with Coraza: https://github.com/corazawaf/coraza-caddy/blob/main/coraza.go#L116-L131.

[LaurenceJJones]

Without looking much deeper into the code, I think this might be what makes the error pages work with Coraza: https://github.com/corazawaf/coraza-caddy/blob/main/coraza.go#L116-L131.

Ahhh so returning that type / struct informs caddy to trigger the pages it has in it directives interesting.

[Simbiat]

If you strip forced MIME types from my config it will be much more tame 😅

I can confirm, that Coraza seems to return something about "Interruption", which I can get from error messages in Caddy, which matches errInterruptionTriggered. So, I guess it's just required to return caddyhttp.HandlerError then. If that's the case, then it could solve the "pluggable" CAPTCHA, too: return 401 for CAPTCHA and 403 for everything else (optionally allow customization), and let users handle 401 with whatever CAPTCHA thing they want.

The only other thing that would be useful here is to have some variable to indicate that 403/401 was caused by CrowdSec, and ideally some details on what triggered the interruption (same as what I've asked for for Coraza module here).

[hslatman]

I can confirm, that Coraza seems to return something about "Interruption", which I can get from error messages in Caddy, which matches errInterruptionTriggered. So, I guess it's just required to return caddyhttp.HandlerError then. If that's the case, then it could solve the "pluggable" CAPTCHA, too: return 401 for CAPTCHA and 403 for everything else (optionally allow customization), and let users handle 401 with whatever CAPTCHA thing they want.

I can see that working, but I think you'll still want that to be connected to the fact that it was CrowdSec that decided a specific action was needed, vs. some other reason a 401 was returned.

The only other thing that would be useful here is to have some variable to indicate that 403/401 was caused by CrowdSec, and ideally some details on what triggered the interruption (same as what I've asked for for Coraza module here).

Yes, I think this is useful, and also ties in with my previous line. I'll see what I can do 🙂

[LaurenceJJones]

I can see that working, but I think you'll still want that to be connected to the fact that it was CrowdSec that decided a specific action was needed, vs. some other reason a 401 was returned.

I agree with @hslatman Captcha is alot more involved, you need to track the request / responses from the Captcha itself rather than looking just for 401 since you need to know when to validate them with the provider. It's something similar I have done on HAProxy SPOA which is using a session cookie which has an internal state.