# Intune Manager - Docker-Test (self-hosted)

Test-Aufbau, um den Intune Manager als Container zu verproben. **Der bestehende
App-/Client-Teil (`Start.ps1`, `src/`, `www/`) wird nicht verändert** — er wird nur
unverändert ins Image kopiert. Container-Spezifika laufen über Env-Variablen und ein
Entrypoint-Script.

> Kein Caddy/TLS enthalten — der **vorhandene Reverse-Proxy** zieht den
> veröffentlichten Port (`8080`) an. HTTPS macht der Proxy.

## Wie es funktioniert
- Die App bindet unverändert auf `http://localhost:8077/` (nur containerintern) und
  bedient — bedingt durch .NET-`HttpListener` — **nur Requests mit `Host: localhost`**.
- Ein **interner nginx** (Port 8080) leitet auf die App weiter und schreibt dabei den
  **`Host`-Header auf `localhost`** um. Ohne dieses Rewrite käme bei Zugriff über IP/Proxy
  ein `404`. Der App-Code bleibt unangetastet.
- Settings/Policy-Exporte liegen im Volume `/data` (`XDG_CONFIG_HOME=/data`, wird von
  `Get-AppDataDir` auf Linux automatisch genutzt).

## Bauen & starten
```bash
docker compose -f docker/docker-compose.yml up --build -d
```
Logs ansehen:
```bash
docker compose -f docker/docker-compose.yml logs -f
```
Erwartet: „Intune Manager - Web Edition" und „URL: http://localhost:8077/".

Den Reverse-Proxy auf `http://<docker-host>:8080` zeigen lassen (reiner HTTP-Proxy,
keine WebSockets/Callbacks nötig).

## Erststart: Verbindung konfigurieren
Beim ersten Start ist noch kein Tenant hinterlegt. Zwei Wege:

- **UI:** Seite öffnen → *Einstellungen* → **Tenant-ID**, **Client-ID** (Read/Write),
  optional **Client-ID (Read-Only)** und **Scopes** eintragen und speichern. Landet in
  `/data/IntuneAppManager-Web/settings.json`.
- **oder** eine vorhandene `settings.json` ins Volume legen:
  ```bash
  docker cp settings.json intune-manager-test:/data/IntuneAppManager-Web/settings.json
  docker compose -f docker/docker-compose.yml restart
  ```

## Login (Device-Code)
Der interaktive „Verbinden"-Button nutzt WAM/Loopback und **funktioniert im Container
nicht** — das ist erwartet. Für den Test den bereits vorhandenen **Device-Code-Flow**
per `curl` anstoßen (Host = euer Reverse-Proxy oder `http://<docker-host>:8080`):

```bash
curl -s -X POST http://<host>/api/connect/start
```
Antwort enthält `code` und `urlComplete`. Dann:
1. `urlComplete` im Browser öffnen und als Admin anmelden.
2. Status pollen, bis verbunden:
   ```bash
   curl -s http://<host>/api/status
   ```
   (Feld `connected` wird `true`.)
3. Die UI im Browser **neu laden** → jetzt verbunden. Geräte/Gruppen/Policies laden
   zum Verifizieren.

## Stoppen / Aufräumen
```bash
docker compose -f docker/docker-compose.yml down          # Daten bleiben im Volume
docker compose -f docker/docker-compose.yml down -v       # inkl. Daten löschen
```

## Wichtige Hinweise (für den echten Einsatz)
- **Kein eigener UI-Login und geteilte Sitzung:** Wer die URL erreicht, kann den Login
  auslösen; die verbundene Graph-Sitzung gilt prozessweit. Die Instanz **zwingend hinter
  Zugangsschutz** stellen (Reverse-Proxy-Auth / Netzsegment / VPN). Eine Instanz =
  eine Team-Sitzung, kein sauberes Multi-Admin.
- Reports liegen unter `/tmp` (nicht persistent) — für den Test ausreichend.
- Das ist ein **Test-Setup**. Echtes Mehrbenutzer (Login pro Admin) wäre ein separater
  Ausbau (Auth-Code-Flow + Sitzungs-Isolation).