Dein Browser wird geprüft! funktioniert ja schon eine Weile wieder GOV/GOV-Tag – GOV leider nicht „out of the box“. Jesper - brauchen wir da eine Anubis-Einstellung oder macht es mehr Sinn den Zugriff - Anubis-Frei durchzuführen oder in der API ein Token oder so etwas zu senden, damit Anubis sich raushält?
Wie bereits besprochen gibt es jetzt einen Work-Around bis das Hauptproblem gelöst wird:
beschreibt die Problematik.
zeigt den Minimalstand wie in MVP: /item/show returns GOV-Kennung and Name · Issue #1 · WolfgangFahl/gov-service · GitHub beschrieben. Meiner Ansicht nach reicht das, um die Migration damit zu starten.
[Hierher verschoben]
Ich hab den besagten Link ausprobiert und das sah auch gut aus 
Nur habe ich festgestellt, dass das ja ein Artikel zum „GOV-Tag xy ist“ und ich wollte sehen ob das auch bei einem Artikel direkt mit Ortsname klappt. Aber gut, wenn das jetzt vorzeitig ausproberit war, dann will nichts gesagt haben
unser extension verwendet einen iframe der ruft anbubis auf weil die Anfrage als extern gilt und dann macht der Browser seinen job - dann ist der browse verwirrt weil er auf gov.genealogy.net eine Aufgabe von einem anderen Server leisten soll. Die Ausgabe ist dann perfekt verwirrend und erweckt den Eindruck das wiki wäre kaputt. Schönen Dank auch! Anfang nächster Woche können wir entscheiden was wir machen, wenn es auf GOV-Seite nicht gelöst wird. Ich hab jetzt mal den offiziellen Kontakt-Link genutzt.
Die Idee mit dem iframe hatte ich auch mal gehabt und dann, wenn ich mich richtig erinnere, wieder verworfen. Stattdessen mit einem url fetch und mit der von Jesper für die Einbindung in Wikis vorgesehenen URL gearbeitet. Aber das ist schon wieder lange her und möglicherweise gab es Anubis damals noch nicht oder es war nicht so streng eingestellt.
iframe stimmt möglicherweise gar nicht mehr - Du hast da vermutlich recht. Aber das spielt für die externe Anfrage keine Rolle weil wir HTML zurückgesendet bekommen. Der neue Service macht content-negotation da kommt wenn man möchte ein JSON oder YAML Ergebnis zurück und wir können das rendering selber machen. Mit HTML kommunizieren ist meiner Ansicht nach für sowas unpassend und eben auch mit reichtlich Folgerproblemen behaftet.
@jzedlitz Da sehr viele Seiten betroffen sind, ist dieses Problem gerade ein entscheidender Flaschenhals für das Genwiki-Update. Ist eine kurzfristige Lösung absehbar? Oder sollte der von Wolfgang benannte Workaround gewählt werden?
Auf dieses Thema bin ich eben erst durch Georgs Erwähnung gestoßen. Ich verstehe die ganze Problematik nicht. Wenn die Anfrage vom GenWiki-Server aus mit einem ordentlichen User-Agent Header kommt (der nicht versucht, einen Browser zu imitieren), dann lässt Anubis diese Anfrage sofort durch.
Alternativ könnte man auch die maschinenlesbaren Daten aus dem GOV über /api/data/ abrufen, aber dann müsste sich die GenWiki-Extension um die komplette Präsentation kümmern.
Im Produktivwiki wird die Anfrage von einer Extension <GOV> gestellt.
Sie läuft auf genwiki39 auch, aber nicht auf genwiki39e.
Sie scheint nicht mit dieser Vorlage identisch zu sein. Das Verhältnis von Extensions und Vorlagen ist mir nicht klar.
Eine Extension ist erst mal notwendig, um das, was zwischen und steht, entgegenzunehmen und „irgendetwas“ damit zu tun. Was damit getan wird, hängt von der Extension selbst ab: Im einfachsten Fall ruft die Extension einfach eine Vorlage auf. Im kompliziertesten Fall ruft sie einzelne Informationen von einem Server (hier: GOV-Server) ab und bereitet daraus eine Darstellung im GenWiki auf. Extensions sind, im Gegensatz zu Vorlagen, nicht für den Wiki-Benutzer sichtbar.
Das wäre, nach meiner bescheidenen Meinung, ein Ansatzpunkt: Warum läuft es im einen Fall problemlos (also mit Darstellung der GOV-Inhalte auf der GenWiki-Seite, wie sie viele GenWiki-Benutzer gefordert hatten, siehe jahrestag-gov-inhalte-werden-im-genwiki-nicht-mehr-angezeigt und warum auf genwiki39e nicht.
@Jesper, laut dem Diskussionsverlauf in
und dem Issue Sign in · GitLab
war die Lage folgende:
Du hattest im November 2025 als Sofortmaßnahme die IP-Adressen der GenWiki-Instanzen in eine Allowlist eingetragen, damit die GOV-Abfragen nicht mehr von Anubis blockiert werden. Die eigentliche Aufgabe — einen ordentlichen User-Agent-Header mitzuschicken — war aber noch offen.
Das ist jetzt erledigt.
Was war das Problem?
Wenn im GenWiki ein Ortsartikel aufgerufen wird (z.B. St. Märgen), holt der
Server im Hintergrund die GOV-Daten von gov.genealogy.net. Dafür hat sich
das GenWiki bisher aber nicht als solches zu erkennen gegeben — es hat bei
der Anfrage keinen „User-Agent" mitgeschickt. Das ist vergleichbar mit jemandem,
der an eine Tür klopft, aber auf die Frage „Wer ist da?" nichts antwortet.
Anubis — die Schutzsoftware vor dem GOV-Server — hat solche anonymen Anfragen
als verdächtig eingestuft und stattdessen eine Prüfseite
(„Dein Browser wird geprüft!") zurückgeschickt. Diese Prüfseite wurde dann
als HTML im GenWiki-Artikel angezeigt, was zu dem merkwürdigen Design führte.
Was wurde geändert?
Zwei Dinge:
-
User-Agent-Header hinzugefügt: Das GenWiki stellt sich jetzt bei jeder
GOV-Anfrage korrekt vor:
CompGenExtension/0.3.1 (MediaWiki; GenWiki; +https://wiki.genealogy.net/GenWiki/CompGen-Extension).
Damit erkennt Anubis sofort, dass es sich um eine legitime Server-zu-Server-Anfrage
handelt — kein Browser, kein Scraper — und lässt sie ohne Prüfung durch. -
Wechsel der HTTP-Methode: Die Anfrage wird jetzt per PHP-Curl statt
file_get_contents()abgesetzt. Der Grund: PHP’s eingebauter HTTP-Client
wird von Anubis trotz korrektem User-Agent weiterhin blockiert (vermutlich
wegen TLS-Fingerprinting), während Curl problemlos durchkommt.
Test
Getestet auf dem Testwiki genwiki39e. Die Seite
GOV/GOV-Tag zeigt nach dem
Fix wieder die echten GOV-Daten (GOV-Kennung, Ortsnamen, Tabellen etc.) —
keine Anubis-Prüfseite mehr.
Die technischen Details zum Fix stehen im Issue:
Bei solchen wichtigen Themen werde ich die in Zukunft per PN informieren.