chore(aws): codify iCaptcha enforce in the EC2 node Terraform#139
Conversation
The AWS EC2 node (manila) was upgraded to v0.4.0 and enabled iCaptcha enforce by hand-editing its running /opt/gitlawb/compose.yaml — which would be lost on instance replacement or a user-data re-run. Codify it so rebuilds stay enforced: - variables.tf: add icaptcha_mode (default "enforce"), icaptcha_pubkey (default the pinned live icaptcha.gitlawb.com Ed25519 key), and icaptcha_required_level (default 3). - main.tf: pass the three vars into the compose templatefile render. - compose.yaml.tftpl: set ICAPTCHA_MODE / ICAPTCHA_PUBKEY / ICAPTCHA_REQUIRED_LEVEL on the node service environment. Operators can override per-deployment via terraform.tfvars.
|
Thanks for the contribution. A couple of things will help us review this faster:
See CONTRIBUTING.md. Update the PR and these notes will clear automatically. |
📝 WalkthroughWalkthroughThis PR adds iCaptcha proof-of-intelligence gate configuration for spam protection. Three new Terraform variables (mode, pubkey, required level) are declared, passed into the compose_yaml templatefile call in main.tf, and consumed as new environment variables in the compose.yaml.tftpl template's node container. ChangesiCaptcha Infrastructure Configuration
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
infra/aws/variables.tf (1)
88-104: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConsider adding
validationblocks for the enum/range constraints.
icaptcha_modeonly acceptsoff | shadow | enforceandicaptcha_required_levelpresumably has a bounded valid range, but neither is enforced by Terraform. A typo interraform.tfvars(e.g."enforce "or"enforced") would silently reach the container as an invalid value.♻️ Optional validation blocks
variable "icaptcha_mode" { description = "iCaptcha gate mode: off | shadow | enforce. The live gitlawb network enforces." type = string default = "enforce" + validation { + condition = contains(["off", "shadow", "enforce"], var.icaptcha_mode) + error_message = "icaptcha_mode must be one of: off, shadow, enforce." + } }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@infra/aws/variables.tf` around lines 88 - 104, Add Terraform validation blocks to the icaptcha variables so invalid values fail fast instead of propagating into the container. Update the variable definitions for icaptcha_mode and icaptcha_required_level in variables.tf: enforce icaptcha_mode to only allow off, shadow, or enforce, and add a numeric range check for icaptcha_required_level using a validation condition. Keep the existing variable names and defaults, and place the new validation logic directly alongside those variable blocks.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@infra/aws/compose.yaml.tftpl`:
- Around line 61-64: The ICAPTCHA_MODE entry in the Compose template is still
unquoted, so YAML may coerce values like off instead of passing the literal
string. Update the environment block in compose.yaml.tftpl so ICAPTCHA_MODE is
quoted like the other string values, keeping the container config aligned with
the icaptcha_mode setting.
---
Nitpick comments:
In `@infra/aws/variables.tf`:
- Around line 88-104: Add Terraform validation blocks to the icaptcha variables
so invalid values fail fast instead of propagating into the container. Update
the variable definitions for icaptcha_mode and icaptcha_required_level in
variables.tf: enforce icaptcha_mode to only allow off, shadow, or enforce, and
add a numeric range check for icaptcha_required_level using a validation
condition. Keep the existing variable names and defaults, and place the new
validation logic directly alongside those variable blocks.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: eae38442-ba02-48b8-ae37-8ba25e7a7749
📒 Files selected for processing (3)
infra/aws/compose.yaml.tftplinfra/aws/main.tfinfra/aws/variables.tf
| # iCaptcha proof-of-intelligence gate (spam protection on create/fork/register) | ||
| ICAPTCHA_MODE: ${icaptcha_mode} | ||
| ICAPTCHA_PUBKEY: ${icaptcha_pubkey} | ||
| ICAPTCHA_REQUIRED_LEVEL: "${icaptcha_required_level}" |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
sed -n '1,120p' infra/aws/compose.yaml.tftplRepository: Gitlawb/node
Length of output: 3370
🏁 Script executed:
rg -n "icaptcha_mode|docker compose|compose version|compose plugin|go-yaml|compose.yaml.tftpl" .Repository: Gitlawb/node
Length of output: 2309
🏁 Script executed:
sed -n '80,120p' infra/aws/variables.tf && printf '\n----\n' && sed -n '1,160p' infra/aws/user-data.sh.tftplRepository: Gitlawb/node
Length of output: 5833
🌐 Web query:
Docker Compose v2.32.4 YAML boolean off on environment mapping compose-go yaml.v3 behavior
💡 Result:
In Docker Compose, including version 2.32.4, the use of unquoted boolean-like values—such as "off", "on", "yes", or "no"—within an environment mapping can cause unexpected behavior or configuration errors because the underlying YAML parser may interpret these as boolean types rather than strings [1][2]. This behavior is primarily a result of Docker Compose using the go-yaml/v3 library for parsing YAML files [3][4]. While YAML 1.2 specifications removed these values from the default boolean set, go-yaml/v3 maintains limited backward compatibility with YAML 1.1 [4]: 1. Boolean Interpretation: When a YAML scalar is decoded into a typed boolean field, values like "off", "on", "yes", and "no" are correctly treated as booleans [4]. However, for environment variable definitions, Docker Compose expects string values [2]. 2. Contextual Parsing: If the YAML parser encounters these values in a context where it expects a string, it may still parse them based on its internal rules, potentially leading to the variable being set as a boolean literal (true/false) instead of the intended string "off" or "on" [2]. 3. Impact on Environment Variables: Docker Compose mandates that any boolean-like value used in the environment section must be enclosed in quotes (e.g., VAR: 'off') [5][6]. Quoting ensures the value is treated strictly as a string, preventing the parser from attempting to convert it into a boolean type [6][2]. If you omit the quotes, you risk configuration errors or the application receiving a boolean type rather than the literal string "off" or "on," which often causes failures in application-level environment variable parsing [2][7]. To ensure consistency and avoid errors, always quote these values in your compose files [6][8].
Citations:
- 1: [BUG] Error "must be a boolean" with
yesscalar in Docker Compose v2.17.0 docker/compose#10465 - 2: https://www.baeldung.com/ops/booleans-docker-compose-yml
- 3: https://github.com/compose-spec/compose-go/blob/main/parsing.md
- 4: https://github.com/go-yaml/yaml/blob/v3/README.md
- 5: https://github.com/compose-spec/compose-spec/blob/a4a7e7c/spec.md
- 6: https://docs.docker.com/reference/compose-file/services/
- 7: Boolean environment variable without quotes convert in string docker/compose#9842
- 8: https://docs.docker.com/compose/how-tos/environment-variables/set-environment-variables/
Quote ICAPTCHA_MODE
icaptcha_mode accepts off, and this Compose environment entry is still unquoted. Docker Compose can treat boolean-like scalars as YAML values here, so off may not reach the container as the literal string. Quoting this field avoids a startup/config mismatch.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@infra/aws/compose.yaml.tftpl` around lines 61 - 64, The ICAPTCHA_MODE entry
in the Compose template is still unquoted, so YAML may coerce values like off
instead of passing the literal string. Update the environment block in
compose.yaml.tftpl so ICAPTCHA_MODE is quoted like the other string values,
keeping the container config aligned with the icaptcha_mode setting.
1 participant
Summary
Codify iCaptcha enforce into the AWS EC2 node Terraform so the enforce config survives instance rebuilds / user-data re-runs.
Motivation & context
The AWS node (manila) was upgraded to v0.4.0 and switched to iCaptcha enforce by hand-editing its running
/opt/gitlawb/compose.yaml. That manual edit would be lost if the EC2 is replaced or user-data re-runs, silently dropping enforcement. This bakes it into the Terraform.Closes #
Kind of change
What changed
infra/aws/variables.tf— new vars:icaptcha_mode(defaultenforce),icaptcha_pubkey(default the pinned liveicaptcha.gitlawb.comEd25519 key),icaptcha_required_level(default3).infra/aws/main.tf— pass the three vars into thecompose.yaml.tftplrender.infra/aws/compose.yaml.tftpl— setICAPTCHA_MODE/ICAPTCHA_PUBKEY/ICAPTCHA_REQUIRED_LEVELon the node service environment.Operators can override any of these per-deployment via
terraform.tfvars.How a reviewer can verify