Sie befinden sich hier: start » de » Interne Dokumentation » DokuWiki-Erweiterungen (WvdS) » Azure DevOps Connector

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 anlegenGeheimnis hinterlegenNetzzugang 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.

Die Collection nicht doppelt angeben. Bei einer On-Premises-Installation (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
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.
Für ein On-Premises-ADO, das auf 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

de/wiki/dwe/wkdoado/start.txt · Zuletzt geändert: von 0.0.0.0