Files
cc-ci-orchestrator/memory/gitea-anubis-ua-challenge.md
T

27 lines
1.6 KiB
Markdown

---
name: gitea-anubis-ua-challenge
description: "Gitea (git.autonomic.zone) sits behind Anubis, which 307-challenges browser-like User-Agents to an un-CORS-able counter-domain — any server-side proxy that forwards a browser UA on behalf of client JS breaks; pin a non-browser UA"
metadata:
node_type: memory
type: project
---
`git.autonomic.zone` sits behind **Anubis** (`anubis.swarm.autonomic.zone`). Anubis
307-challenges requests whose User-Agent looks like a real browser to
`/.within.website/?redir=…` — a JS proof-of-work challenge page on a *different* origin with
**no CORS headers**.
Impact: any server-side proxy that serves client-side JS but forwards the *end browser's* UA
hits this asymmetry — `curl` (non-browser UA) passes through cleanly, a real Firefox/Chrome UA
gets the 307. Concretely: the Recipe Report's same-origin PR-STATUS proxy
(`report./pr/<recipe>/<n>`, cc-ci `nix/modules/reports.nix`) forwarded the browser UA, so
every live cell in the browser rendered `?` (week-2026-09-11, operator-CORS console report).
Fix (cc-ci PR #38, merged 2026-09-14): `proxy_set_header User-Agent "ccci-reports-proxy/1.0";`
in the `/pr/` nginx location — a stable non-browser UA passes Anubis unmolested. Deployed via
`nix flake update cc-ci``nixos-rebuild test` → health → `switch` (flake.lock commit).
Rule of thumb: server-side callers of the Gitea API (scripts, proxied fetches, harness code
running in a browser's name) must pin a non-browser User-Agent or cookie-carry; browser-visit
flows keep the JS challenge and that's fine. Related: [[recipe-mirrors-public-org-blocker]].