Anubis-Standardrichtlinie prüft Bilder, API und POST-Anfragen - Nutzer verlieren Änderungen, Anmeldung schlägt fehl (Discourse 844802)

Zusammenfassung

Anubis läuft auf wiki.genealogy.net mit der eingebauten Standard-Richtlinie — die docker-compose.yml (RCS-versioniert, unverändert seit 2026-03-12) bindet keine botPolicies-Datei ein und setzt nur DIFFICULTY=4. Die Standard-Richtlinie prüft jede browser-artige Anfrage auf jedem Pfad, also auch statische Inhalte (Bilder, CSS), API-Aufrufe und POST-Anfragen. Das ist die Ursache der Beschwerden im Discourse-Thema „Abmeldung/Anubis-Probleme" (844802) vom 04./05.07.2026.

Symptome aus Nutzersicht (Discourse 844802)

Wiederholte Anubis-Prüfungen, teils bei jedem Seitenaufruf (Beiträge 1, 4, 6)
An-/Abmelden schlägt wiederholt fehl mit „Ungültige Server-Antwort" (Beiträge 1, 6)
Bearbeiteter Text geht beim Vorschau/Speichern unwiederbringlich verloren (Beiträge 1, 6)
Kaputte Seitendarstellung: fehlende Icons/Bilder, fehlende Anmelden-Schaltfläche, erst nach mehrfachem Aktualisieren behoben (Beitrag 6)

Belege (vm2180, geprüft am 2026-07-07)

Container anubis-anubis-1 hat keine Mounts und keine Policy-Umgebung — Standard-Richtlinie aktiv (docker inspect).
339.389 Prüfungen seit 06.07. 00:00 (~1,5 Tage ≈ 9.400/h), davon 103 auf POST und 366 auf HEAD.
Beispiel (erste erhaltene Log-Zeile, 06.07. 07:05): Prüfung für GET /images/thumb/a/a0/Karkeln_Ansichtskarte.jpg/900px-... an einen normalen Android-Chrome-Browser — d. h. schon einfache Bild-Anfragen werden geprüft, was die kaputten Seiten erklärt.
Eine geprüfte POST-Anfrage verschluckt die Formulardaten → Textverlust; eine geprüfte API/XHR-Anfrage liefert Challenge-HTML statt JSON → „Ungültige Server-Antwort".
Das Apache-wiki.log vom 04./05.07. zeigt keine serverseitige Verschlechterung: konstant 20–30k Anfragen/h, genau 2× HTTP 500 pro Tag, jeder Special:UserLogin-POST mit 302 beantwortet. Load ~1,0, Uptime 89 Tage. Die Fehler entstehen vor Apache, in der Anubis-Schicht.
Die Anubis-Logs vom 04./05.07. sind rotiert (json-file 3×100m), daher die Quantifizierung vom 06./07.07. — die Konfiguration hat sich dazwischen nicht geändert, der Mechanismus ist derselbe.

Zusammenhang mit den MW-1.43-Migrationsarbeiten

Am 05.07. liefen auf vm2180 ein Produktions-DB-Dump (16:38–17:00 MESZ) und der Bilder-Seed-rsync (ab ~17:21 MESZ); zwei Beschwerde-Beiträge fallen genau in diese Fenster. Das Apache-Log zeigt jedoch durchgehend unverminderte Auslieferung — die Migrationslast war höchstens ein kleiner Verstärker. Die erste Beschwerde (04.07., 20:16 MESZ) liegt vor allen diesen Arbeiten. Künftige Wartungsfenster kündigen wir trotzdem vorher an.

Lösungsvorschlag

Explizite botPolicies.yaml einbinden (RCS-versioniert neben der docker-compose.yml) statt der Standard-Richtlinie:
- ALLOW für statische Inhalte und MediaWiki-Interna: /images/, /skins/, /resources/, /load.php, /api.php, /rest.php, /favicon.ico, /robots.txt
- ALLOW für alle POST-Anfragen (mindestens api.php und index.php?action=submit|raw) — eine Prüfung auf POST zerstört immer Nutzerdaten; geprüft wird nur der erste Seitenaufruf (GET)
- CHALLENGE bleibt für generische Browser-GETs auf Artikelpfaden
Gültigkeit des Challenge-Cookies prüfen (JWT-Laufzeit, Standard 1 Woche), sodass eine Prüfung pro Browser und Woche der Normalfall ist; die wiederholten Prüfungen zeigen, dass das Cookie heute bei Asset-/API-Anfragen nicht greift.
Den Bot-Bypass aus #90 (Token-Header / CEL) in derselben Policy-Datei umsetzen, damit vertrauenswürdige Werkzeuge (sync_wiki, wikipush, Monitoring) ohne PoW durchkommen.
Image-Version festnageln (aktuell ghcr.io/techarohq/anubis:latest — Verhalten ändert sich mit jedem Pull) und DIFFICULTY=4 überdenken (langsam auf älteren Geräten).
Dieselbe Policy auf wiki43 anwenden (update-auf-1.43#12 hat die Konfiguration bereits im Repo), damit der 1.43-Umstieg mit korrekten Einstellungen live geht.
Die bereits exponierten Prometheus-Metriken (:9091) nutzen, um die Challenge-Rate vorher/nachher zu beobachten — Ziel: Prüfung nur beim Erstbesuch, null auf POST/Assets.

Summary

Anubis on wiki.genealogy.net runs with the built-in default policy — the docker-compose.yml (RCS-tracked, unchanged since 2026-03-12) mounts no botPolicies file and sets only DIFFICULTY=4. The default policy challenges every browser-like request on every path, including static assets, API calls and POST requests. This is the root cause of the usability complaints in Discourse topic "Abmeldung/Anubis-Probleme" (844802) of 2026-07-04/05.

User-visible symptoms (Discourse 844802)

Repeated Anubis challenges, sometimes on every page (posts 1, 4, 6)
Login/logout fails repeatedly with "Ungültige Server-Antwort" (posts 1, 6)
Edit text irretrievably lost on preview/save (posts 1, 6)
Broken page renders: missing icons/images, missing login button, fixed only by rapid refreshes (post 6)

Evidence (vm2180, checked 2026-07-07)

Container anubis-anubis-1 has no mounts and no policy env — default policy active (docker inspect).
339,389 challenges issued since 2026-07-06 00:00 (~1.5 days ≈ 9,400/h), of which 103 POST and 366 HEAD challenges.
Example (first surviving log line, Jul 6 07:05): challenge issued for GET /images/thumb/a/a0/Karkeln_Ansichtskarte.jpg/900px-... to a regular Android Chrome browser — i.e. plain image subrequests get challenged, which explains the broken renders.
A challenged POST swallows the form body → lost edits; a challenged API/XHR request returns challenge HTML instead of JSON → "Ungültige Server-Antwort".
Apache wiki.log for Jul 4–5 shows no server-side degradation: steady 20–30k requests/h, exactly 2× HTTP 500 per day, every Special:UserLogin POST answered 302. Load average ~1.0, uptime 89 days. The failures happen in front of Apache, at the Anubis layer.
Anubis logs for Jul 4–5 are gone (json-file rotation 3×100m), hence quantification from Jul 6–7 — the config has not changed in between, so the mechanism is the same.

Relation to the MW 1.43 migration work

On Jul 5 a production DB dump (16:38–17:00 CEST) and the images seed rsync (from ~17:21 CEST) ran on vm2180; two complaint posts fall exactly into these windows. However the Apache log shows undiminished serving throughout, so the migration load was at most a minor aggravator. The first complaint (Jul 4, 20:16 CEST) predates any of that work. We should nevertheless announce maintenance windows beforehand in the future.

Proposed fix

Mount an explicit botPolicies.yaml (RCS-tracked next to docker-compose.yml) instead of relying on the default policy:
- ALLOW static assets and MediaWiki internals: /images/, /skins/, /resources/, /load.php, /api.php, /rest.php, /favicon.ico, /robots.txt
- ALLOW all POST requests (or at minimum api.php and index.php?action=submit|raw) — a challenge on POST always destroys user data; challenge only top-level GET page views
- keep CHALLENGE for generic browser GETs on article paths
Verify challenge-cookie validity (JWT lifetime, default 1 week) so one challenge per browser per week is the norm; repeated challenges indicate the cookie is not being honored for asset/API subrequests today.
Implement the bot bypass from #90 (token header / CEL) in the same policy file so trusted tools (sync_wiki, wikipush, monitoring) pass without PoW.
Pin the image version (currently ghcr.io/techarohq/anubis:latest — behavior drifts on every pull) and reconsider DIFFICULTY=4 (slow on older devices).
Apply the identical policy to wiki43 (update-auf-1.43#12 already has the config in the repo) so the 1.43 cutover goes live with correct settings.
Use the already exposed Prometheus metrics (:9091) to watch the challenge rate before/after — target: challenges only on first visit, zero on POST/assets.

Erstellt von Agent/Ward (KI-Agent) unter Human-in-the-Loop-Aufsicht von Wolfgang Fahl. / Filed by Agent/Ward (AI agent) under human-in-the-loop supervision of Wolfgang Fahl.

Edited Jul 07, 2026 by Wolfgang Fahl