Files

T

schalli f1ecbf542e test(tender-radar): Verbindungstest abgenommen (#16 zu), Postfach-Test zurueckgestellt

Abnahme im Browser auf alpha gegen den echten Exchange owa.ctl.de, nachdem die
Container mit --force-recreate getauscht waren. Der blosse pull genuegte nicht:
die neue Route fehlte im laufenden Container und war im gezogenen Image
vorhanden — hart belegt statt vermutet.

Alle vier Punkte bestanden:
- gespeicherte Konfiguration mit LEEREM Passwortfeld meldet "Verbindung
  erfolgreich" — belegt zugleich den Rueckgriff auf die gespeicherten
  verschluesselten Zugangsdaten
- absichtlich falscher Server meldet "Verbindung fehlgeschlagen: getaddrinfo
  ENOTFOUND owa-gibtsnicht.ctl.de"
- keine Zugangsdaten im API-Protokoll (die Treffer einer Mustersuche waren
  Routennamen wie /auth/reset-password)
- der Test schreibt nichts; die gespeicherte Konfiguration blieb unveraendert

Nebenbefund mit Gewicht: das Protokoll zeigt eine echte Antwort von Exchange
2019 (ServerVersionInfo 15.2) samt aufgeloester FolderId. Der in Plan 14-03 als
fragil markierte, handgeschriebene NTLM/SOAP-Weg ist damit erstmals gegen einen
echten Server gemessen — bisher lag nur gemocktes httpntlm.post vor.

WINDOWS #12 zurueckgestellt (waived): es gibt intern kein Postfach, in das
Ausschreibungs-Alarme hereinkommen. Ein frueheres Missverstaendnis hatte eines
angenommen. Nachzuholen, sobald ein solches Postfach existiert; offen ist dann
allein das Einlesen einer echten Alarm-Mail.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU

2026-09-09 07:21:36 +02:00

3.1 KiB

Raw Blame History

Abnahme im Browser — 2026-09-09

Durchgefuehrt auf alpha (https://alpha.tessera.ctl.de) gegen den echten Exchange-Server owa.ctl.de, nachdem die Container mit dem neuen Image neu erstellt wurden. Schliesst WINDOWS.md #16.

Voraussetzung: Container tatsaechlich getauscht

Der blosse pull genuegte nicht — die Container liefen 41 Stunden alt weiter. Hart belegt statt vermutet: die neue Route war im gezogenen Image vorhanden und im laufenden Container nicht.

laufender Container: grep "email-config/test" /app/apps/api/dist  → nichts
neues Image:         grep "email-config/test" /app/apps/api/dist  → 3 Treffer

Nach docker compose up -d --force-recreate api web ist die Route gemappt:

[RouterExplorer] Mapped {/modules/tender-radar/email-config/test, POST} route

Die vier Abnahmepunkte

#	Pruefung	Ergebnis
1	Gespeicherte Konfiguration, Passwortfeld leer	"Verbindung erfolgreich" — belegt zugleich den Rueckgriff auf die gespeicherten verschluesselten Zugangsdaten, denn das Passwort wird nie an die Oberflaeche zurueckgegeben
2	Absichtlich falscher Server (`owa-gibtsnicht.ctl.de`)	"Verbindung fehlgeschlagen: getaddrinfo ENOTFOUND owa-gibtsnicht.ctl.de" — rot, mit der echten Meldung
3	Zugangsdaten im API-Protokoll	keine. Die drei Treffer einer Mustersuche waren Routennamen beim Start (`/auth/reset-password` und Geschwister), keine Daten
4	Schreibt der Test etwas?	nein — die gespeicherte Konfiguration war nach beiden Laeufen unveraendert

Belege: uat-2026-09-09/w16-verbindung-erfolgreich.png, uat-2026-09-09/w16-verbindung-fehlgeschlagen.png

Nebenbefund mit Gewicht: der EWS-Weg laeuft gegen den echten Server

Das API-Protokoll des erfolgreichen Laufs zeigt eine echte Antwort von Exchange 2019, nicht von einer Attrappe:

[ExchangeInboxProvider] EWS FindFolder response for "DKV":
  <s:Header><h:ServerVersionInfo MajorVersion="15" MinorVersion="2"
  MajorBuildNumber="2562" MinorBuildNumber="46" .../></s:Header>
[ExchangeInboxProvider] EWS FindFolder: resolved "DKV" → FolderId AAAQAGtzY2hhbGxlckBj…

Damit ist der handgeschriebene NTLM/SOAP-Weg erstmals gegen einen echten Exchange-Server gemessen: Anmeldung, FindFolder und Ordneraufloesung funktionieren. Genau dieser Verbindungsaufbau war in Plan 14-03 als "documented-fragile" markiert und bisher nur gegen gemocktes httpntlm.post geprueft.

Ausdruecklich NICHT belegt

Das Einlesen einer echten Alarm-Mail (WINDOWS #12). Dafuer gibt es intern derzeit kein Postfach, in das Ausschreibungs-Alarme hereinkommen — Entscheidung des Users vom 2026-09-09, der Punkt ist im Ledger zurueckgestellt. Der hier gepruefte Ordner DKV enthaelt Tankkarten-Rechnungen und diente nur als erreichbares Ziel fuer den Verbindungsaufbau.

Beobachtung fuer spaeter (kein Mangel)

Der ExchangeInboxProvider schreibt die vollstaendige SOAP-Antwort als DEBUG-Zeile ins Protokoll. Das ist sehr gespraechig; Zugangsdaten stehen nicht darin, aber vor einem Produktivbetrieb waere zu ueberlegen, ob diese Ausgabe dort noch sinnvoll ist.

3.1 KiB Raw Blame History