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
feat(go): share detection state through Redis (#43)
* feat(go): share detection state through Redis
* fix(helm): close validateSecret before the new shared-state define
The shared-state guard was added between validateSecret's inner {{ end }}
and the one closing the define, so the new define nested inside it and
the chart stopped parsing: 'unexpected <define> in command'. Neither the
guard nor any other template rendered.
Closes validateSecret first and drops the now-stray trailing end. Checked
with helm lint plus template renders at one replica, at three without
Redis (guard fires), and at three with Redis.
* ci(helm): give the multi-replica render combinations a Redis URL
autoscaling.enabled implies more than one pod, which the new shared-state
guard now refuses without Redis, so the scaling and full combinations
stopped rendering. Both get a Redis URL, which is what the chart is
telling operators to do.
Adds a guard test alongside the signing-key one: three replicas without
Redis, and autoscaling without Redis, must both refuse to render.
---------
Co-authored-by: Chris Portscheller <home@mac-mini.lan>
| `FCAPTCHA_INSECURE_DEV_MODE` | No | off | Explicitly use the public development signing key for local-only development. Never expose a server with this enabled |
442
-
| `REDIS_URL` | No | - | Go only: Redis URL for shared PoW, token replay, and Siteverify idempotency state. Configuration is fail-closed; it does not yet make every store distributed |
440
+
| `REDIS_URL` | No | - | Go only: Redis URL for shared security state. Required for multiple replicas; configuration and runtime failures are fail-closed |
443
441
| `FCAPTCHA_VERIFY_SECRET` | No | `FCAPTCHA_SECRET` | Credential your backend sends as `secret` when verifying a token. Split it from the signing key so a leaked verify credential cannot also mint tokens |
444
442
| `FCAPTCHA_LEGACY_UNAUTH_VERIFY` | No | off | Restore the pre-1.22.0 behaviour where token verification accepted any caller. Migration cover for one release — see [Upgrading to 1.22.0](#upgrading-to-1220) |
445
443
| `FCAPTCHA_ALLOWED_HOSTNAMES` | No | (any) | Comma-separated hostnames permitted to mint tokens, matched against the request `Origin` (then `Referer`) |
Copy file name to clipboardExpand all lines: charts/fcaptcha/templates/_helpers.tpl
+9Lines changed: 9 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -61,3 +61,12 @@ to do by accident, and it costs one line of setup to satisfy.
61
61
{{- fail "\n\nfcaptcha: a token signing key is required.\n\n --set secret=$(openssl rand -hex 32)\n\nor point at one you already manage:\n\n --set existingSecret=my-fcaptcha-secret\n\nWithout it the server falls back to a key published in its own source, and\nanyone can mint tokens your backend will accept.\n" -}}
62
62
{{- end -}}
63
63
{{- end -}}
64
+
65
+
{{/* Multiple Go pods require shared security state. */}}
0 commit comments