Azure DevOps Connector
Azure DevOps Connector ist die gehärtete Verbindung des Wikis zu Azure DevOps: Verbindungsverwaltung, Anmeldung, REST-Zugriff und Diagnose. Er synchronisiert nichts und speichert kein Geheimnis im Klartext. Gedacht ist das Paket für Verwalter, die eine ADO-Organisation anbinden, und als Unterbau für die Pakete, die darauf aufsetzen.
Erste Schritte
Schnelleinstieg: Die erste Azure-DevOps-Verbindung – der kürzeste Weg zum ersten Ergebnis, in vier Schritten.
Verbindung anlegen → Geheimnis hinterlegen → Netzzugang prüfen
Häufige Aufgaben
| Was Sie wollen | Für wen | Wo Sie das tun | Anleitung |
|---|---|---|---|
| eine Verbindung zu Azure DevOps anlegen | Verwaltung | do=wkdoado auf einer Projektseite | Verbindungen anlegen |
| ein Geheimnis hinterlegen, ohne es einzutragen | Verwaltung | Verweis auf wkvault | Geheimnisse |
| verstehen, warum beim Schreiben ein zweiter Faktor verlangt wird | Verwaltung | – | Zweiter Faktor beim Schreiben |
| den ausgehenden Netzzugang einstellen | Verwaltung | Konfigurationsmanager | Netzwerk-Härtung |
prüfen, ob die Voraussetzung curl erfüllt ist | Verwaltung | – | curl ist Voraussetzung |
| ein ADO-Repository im Wiki zeigen | Autor | – | ADO-Git |
| wissen, was dieses Paket nicht leistet | alle | – | Grenzen |
Zweck
Die gehärtete Verbindung zu Azure DevOps: Verbindungsverwaltung, Authentifizierung, REST-Client und Diagnose. Es synchronisiert nichts und speichert keine Klartext-Geheimnisse – es stellt nur den Weg bereit, den andere Plugins benutzen.
Angemeldeter Dienst (siehe Core Plugin): ado.client. Hauptverbraucher ist
wkdoadogit.
Verbindungen anlegen
Auf einer Projektseite: ?do=wkdoado. Eine Verbindung gehört immer zu einem Projekt
(siehe DevOps Core) und wird in dwdo_ado_connections abgelegt.
deployment = server) enthält die Basis-URL die Collection bereits, z. B.
https://devops.wvds.it/Me. Wird das Feld Collection zusätzlich gefüllt, hängt der
Endpunktbauer sie ein zweites Mal an — jeder REST-Aufruf endet dann in einem HTTP 404, ohne
dass die Meldung den Grund nennt. Entweder Basis-URL oder eigenes Feld, nie beides.
Geheimnisse
Das PAT gehört nicht in die Datenbank. Hinterlegt wird ein Verweis, den der
SecretResolver zur Laufzeit auflöst:
| Verweis | Bedeutung |
|---|---|
vault:{id} | Eintrag im Tresor wkvault – empfohlen: Der Eintrag bringt ein Ablaufdatum, eine Übergabe bei der Rotation und ein Protokoll jedes Lesezugriffs mit. Ohne das Plugin wird dieser Verweis abgelehnt; die anderen bleiben unberührt. |
file:{dateiname} | Datei unterhalb des in ado_secret_root konfigurierten Verzeichnisses |
env:{name} | Umgebungsvariable |
enc:… | verschlüsselt abgelegter Wert |
ado_secret_root ist leer voreingestellt und damit abgeschaltet. Ohne gesetztes Verzeichnis
löst kein file:-Verweis auf. Der Auflöser prüft zusätzlich, dass die Datei tatsächlich
unterhalb dieses Verzeichnisses liegt — ein Verweis mit .. kommt nicht heraus.
Zweiter Faktor beim Schreiben eines Verweises
[Live seit 2026-08-09] Über den Identity Plugin Contract v1
(Identity Plugin Contract v1) abgesichert: eine Brücke do=wkdoado_stepup mit fest verdrahteter
Kategorienliste.
| Kategorie | Anforderung | Gilt für |
|---|---|---|
secret-write | MFA_ANY | Einen Geheimnis-Verweis setzen oder ändern |
remove | MFA_ANY | Eine Verbindung entfernen |
Die Prüfung ist zusätzlich zur DokuWiki-Zugriffsliste, nie an ihrer Stelle. Ist wkidentity
nicht installiert, verhält sich das Paket unverändert — eine bewusste, dokumentierte Grenze, kein
verstecktes Verhalten. Die Brücke nimmt nie eine vom Aufrufer gelieferte Anforderung entgegen, nur
einen Namen aus ihrer eigenen Liste; ein unbekannter Name ergibt eine Ablehnung.
Netzwerk-Härtung
| Einstellung | Vorgabe | Bedeutung |
|---|---|---|
ado_host_allow | leer | erlaubte Ziel-Hostnamen, exakt. Leer = alles verboten |
ado_allow_private | 0 | Ziele in privaten/Loopback-Netzen erlauben — nötig für On-Prem-ADO |
ado_ca_bundle | leer | eigenes CA-Bündel; die TLS-Prüfung ist immer an |
ado_connect_timeout | 5 s | Verbindungsaufbau |
ado_timeout | 20 s | gesamter Aufruf |
ado_max_bytes | 1048576 | Obergrenze der Antwort |
ado_max_retries | 2 | zusätzliche GET-Versuche bei Ratenbegrenzung/Transportfehler |
ado_host_allow ist standardmäßig eine leere Liste, und eine leere Liste verbietet alles.
Das ist die richtige Voreinstellung für einen Client, den Seiteninhalt erreichen kann — aber der
häufigste Grund, warum eine frisch angelegte Verbindung „inaktiv“ meldet, obwohl PAT und URL
stimmen.
127.0.0.1 auflöst (wie devops.wvds.it auf dieser
Instanz), sind beide Schalter nötig: Hostname in ado_host_allow und
ado_allow_private = 1. Der zweite ist ein bewusstes Opt-in, weil er den Schutz vor
serverseitigem Anfragenschmuggel (SSRF) in private Netze aufhebt.
curl ist Voraussetzung, nicht Zubehör
Der gesamte REST-Weg läuft über curl; AdoRestClient::available() ist schlicht
function_exists('curl_init'). Fehlt die Erweiterung, meldet der Konnektor „inaktiv“ und jeder
darauf aufbauende Bildschirm bleibt leer.
Der portable Server brachte curl nicht mit; wie nachinstalliert wurde, steht bei Inbetriebnahme.
Grenzen
- Kein Abgleich von Arbeitselementen — die Tabellen dafür liegen bereit (siehe DevOps Storage Plugin), das zuständige Plugin ist nicht installiert.
- Eine Verbindung authentifiziert stets mit einem PAT; die Identität des einzelnen Wiki-Nutzers erreicht ADO darüber nicht.
Paketangaben
Plugin: wkdoado
Namespace: lib/plugins/wkdoado/
Autor: Wolfgang van der Stille Wolfgang.van.der.Stille@gmail.com (The White Knight Labs)
Lizenz: GPL 2