schalli
f1ecbf542e
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
68 lines
3.1 KiB
Markdown
68 lines
3.1 KiB
Markdown
# 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.
|