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
{{ message }}
Repository navigation
How to push a PR to add support for ALTCHA (on premise) #151
I have implemented support for ALTCHA (a privacy-friendly, self-hosted Proof-of-Work CAPTCHA alternative) in the Nginx Lua Bouncer on my installation, and it works without any external cloud dependencies.
To enable it, the configuration in crowdsec-nginx-bouncer.conf simply uses:
CAPTCHA_PROVIDER=altcha
SECRET_KEY= # Result of `openssl rand -hex 32`
SITE_KEY=ALTCHA_LOCAL # Mandatory config parameter, though not used by ALTCHA
CAPTCHA_TEMPLATE_PATH=/var/lib/crowdsec/lua/templates/altcha.html
Overview of modified / created files:
captcha.lua: Minimal modifications to support the ALTCHA provider integration.
altcha.lua: Helper module to generate challenges and verify the Proof-of-Work submitted by the client.
altcha.html: Multilingual template (English with French auto-detection) rendering the widget with a "Continue" button.
altcha.min.js: Minified script fetched from the official ALTCHA repo (dist/main/altcha.min.js).
crowdsec_altcha.conf: Nginx snippet to include in vhosts to handle the /altcha-challenge and /altcha.js locations.
Everything is tested and fully working on my setup. I would love to open a Pull Request on GitHub to contribute this back to the community, but this is my first contribution to the CrowdSec ecosystem, so I’d appreciate some guidance on the project's structure:
Should the Nginx snippet (crowdsec_altcha.conf) be included directly in cs-nginx-bouncer (e.g., under a snippets/ or conf/ folder and handled in (un)install.sh), or should it belong to cs-nginx-bouncer?
Are there any specific guidelines or test suites I should run before submitting the PR?
I have already cloned the repository and created a dedicated feature branch with all my changes.
changed the title [-]Support for self-hosted ALTCHA CAPTCHA provider (PR guidance)[/-][+]How to make a PR to give my support for ALTCHA (on premise)[/+]on Aug 1, 2026
changed the title [-]How to make a PR to give my support for ALTCHA (on premise)[/-][+]How to push a PR to add support for ALTCHA (on premise)[/+]on Aug 1, 2026
Thanks for the proposal. ALTCHA support sounds like a good fit here, especially for self-hosted / no external CAPTCHA dependency setups.
For the repository split, I would structure it like this:
- lua-cs-bouncer: keep the generic provider support here. That includes the Lua implementation (captcha.lua changes and the altcha.lua helper), the ALTCHA captcha template, config example updates, and tests.
- cs-nginx-bouncer: keep nginx packaging/integration snippets here. If ALTCHA needs additional nginx location blocks such as /altcha-challenge and /altcha.js, those should go in the nginx bouncer repo as a clear optional example, probably next to nginx/crowdsec_nginx.conf, rather than something enabled automatically by the default install flow.
- cs-openresty-bouncer: please keep this in line with the nginx bouncer as well. The lua library is shared by both projects, so any optional nginx-side example, template path, or documentation change needed for ALTCHA should have the equivalent OpenResty change or at least be called out in the PR.
So I would suggest opening the first PR against crowdsecurity/lua-cs-bouncer with the provider support itself. If that PR needs nginx snippet changes to show how ALTCHA should be wired in a vhost, open a second PR against crowdsecurity/cs-nginx-bouncer with that as a optional example (maybe in a separate file), and check whether the same example is needed in crowdsecurity/cs-openresty-bouncer. Please link the related PRs together.
Before opening the PR, please include:
- an update to config_example.conf, changing the provider comment from recaptcha, hcaptcha, turnstile to include altcha;
- a test under t/ covering the ALTCHA provider path. The existing captcha tests (t/13_stream_captcha_and_deletion.t and t/14_stream_captcha_and_cache.t) are good examples of the
style;
- if possible, a validation test for both challenge generation and proof verification without requiring network access;
- a short note in the PR description explaining whether altcha.min.js is vendored, where it comes from, and which upstream version / license it corresponds to.
The current CI installs dependencies and runs the Perl nginx test suite with:
Locally, the same tests require nginx with the Lua module, lua-cjson, lua-resty-http, Test::Nginx, and Test::Nginx::Socket. If you cannot run the whole suite locally, please mention that in the PR description and include the exact setup where you tested it manually.
Two implementation points to watch for:
- ALTCHA should not make the existing cloud CAPTCHA providers regress. Keeping provider-specific code isolated, for example in plugins/crowdsec/altcha.lua, is preferable to making captcha.lua too branch-heavy.
- If SITE_KEY is not actually needed by ALTCHA, it would be better not to require a fake value long term. If changing that is too invasive for the first PR, mention it explicitly so we
can decide whether to accept the compatibility placeholder or adjust config validation.
Thanks for the answer and the guidance. I don't really understand how to create the "t/" file, so I'll go ahead and make the PR as is — perhaps someone else could complete it afterwards.
When all will be ok i will push also a pr in crowdsecurity/cs-openresty-bouncer
Activity
[-]Support for self-hosted ALTCHA CAPTCHA provider (PR guidance)[/-][+]How to make a PR to give my support for ALTCHA (on premise)[/+][-]How to make a PR to give my support for ALTCHA (on premise)[/-][+]How to push a PR to add support for ALTCHA (on premise)[/+]sabban commentedon Sep 1, 2026
└ Hi @clionelc,
Thanks for the proposal. ALTCHA support sounds like a good fit here, especially for self-hosted / no external CAPTCHA dependency setups.
For the repository split, I would structure it like this:
-
lua-cs-bouncer: keep the generic provider support here. That includes the Lua implementation (captcha.luachanges and thealtcha.luahelper), the ALTCHA captcha template, config example updates, and tests.-
cs-nginx-bouncer: keep nginx packaging/integration snippets here. If ALTCHA needs additional nginxlocationblocks such as/altcha-challengeand/altcha.js, those should go in the nginx bouncer repo as a clear optional example, probably next tonginx/crowdsec_nginx.conf, rather than something enabled automatically by the default install flow.-
cs-openresty-bouncer: please keep this in line with the nginx bouncer as well. The lua library is shared by both projects, so any optional nginx-side example, template path, or documentation change needed for ALTCHA should have the equivalent OpenResty change or at least be called out in the PR.So I would suggest opening the first PR against
crowdsecurity/lua-cs-bouncerwith the provider support itself. If that PR needs nginx snippet changes to show how ALTCHA should be wired in a vhost, open a second PR againstcrowdsecurity/cs-nginx-bouncerwith that as a optional example (maybe in a separate file), and check whether the same example is needed incrowdsecurity/cs-openresty-bouncer. Please link the related PRs together.Before opening the PR, please include:
- an update to
config_example.conf, changing the provider comment fromrecaptcha, hcaptcha, turnstileto includealtcha;- a test under
t/covering the ALTCHA provider path. The existing captcha tests (t/13_stream_captcha_and_deletion.tandt/14_stream_captcha_and_cache.t) are good examples of thestyle;
- if possible, a validation test for both challenge generation and proof verification without requiring network access;
- a short note in the PR description explaining whether
altcha.min.jsis vendored, where it comes from, and which upstream version / license it corresponds to.The current CI installs dependencies and runs the Perl nginx test suite with:
Locally, the same tests require nginx with the Lua module,
lua-cjson,lua-resty-http,Test::Nginx, andTest::Nginx::Socket. If you cannot run the whole suite locally, please mention that in the PR description and include the exact setup where you tested it manually.Two implementation points to watch for:
- ALTCHA should not make the existing cloud CAPTCHA providers regress. Keeping provider-specific code isolated, for example in
plugins/crowdsec/altcha.lua, is preferable to makingcaptcha.luatoo branch-heavy.- If
SITE_KEYis not actually needed by ALTCHA, it would be better not to require a fake value long term. If changing that is too invasive for the first PR, mention it explicitly so wecan decide whether to accept the compatibility placeholder or adjust config validation.
Regards,
lctwo commentedon Sep 4, 2026
Hi,
Thanks for the answer and the guidance. I don't really understand how to create the "t/" file, so I'll go ahead and make the PR as is — perhaps someone else could complete it afterwards.
When all will be ok i will push also a pr in crowdsecurity/cs-openresty-bouncer
#156