azure-database-tui/README.md

# Azure Database TUI

This repository contains a Rust TUI for administering Azure Database for
PostgreSQL flexible servers. It discovers servers through the current Azure CLI
tenant and connects to PostgreSQL using mandatory TLS.

## Prerequisites

Install Azure CLI and authenticate to the intended tenant. Network access to
the server endpoint, including private endpoint, firewall, and DNS access, is
required. Azure CLI visibility does not imply PostgreSQL authorization.

## Build and test

The repository contains a checked-in dependency lock. Use the pinned Rust
toolchain with `cargo build --locked` and `cargo test --locked`. The initial
working screen discovers Flexible Servers through Azure CLI; the lower-level
domain and service modules provide the foundations for profiles, table actions,
roles and the SQL workspace.

Supported release targets are macOS ARM64 and Windows x86_64. Raw SQL is sent
to PostgreSQL as entered; use it only when you understand its authority and
effects.

See [security](docs/security.md), [operations](docs/operations.md), and
[release](docs/release.md).




- Native, performante Rust-TUI zur Administration von Azure Database for PostgreSQL Flexible Server.
- Unterstützung ausschließlich für macOS ARM64 und Windows x86_64 als Release-Ziele.
- Nutzung der vorhandenen Azure CLI und des aktuell angemeldeten Azure-Tenants.
- Ermittlung aller sichtbaren aktiven Subscriptions im aktuellen Tenant.
- Ermittlung aller sichtbaren Azure PostgreSQL Flexible Server über diese Subscriptions hinweg.
- Serverauswahl in der TUI.
- Anzeige und Auswahl der verfügbaren Datenbanken eines Servers.
- Datenbank-Lifecycle über Azure: Datenbanken auflisten, erstellen und löschen.
- Schutz von Systemdatenbanken wie postgres und Azure-reservierten Datenbanken vor geführtem Löschen.
- Datenbank-Drop nur mit expliziter Bestätigung und exakter Zielangabe.
- Lokale, wiederverwendbare Verbindungsprofile:
- Azure-Ressourcenreferenz,
- Server/FQDN,
- Port,
- Datenbank,
- PostgreSQL-Benutzername,
- TLS-Konfiguration,
- optionale Keychain-Referenz.
- Keine Klartextpasswörter in Profildateien.
- Speicherung von Passwort-Referenzen im macOS Keychain bzw. Windows Credential Manager.
- Falls Keychain nicht verfügbar ist: nur sitzungsgebundene Passworteingabe, kein Klartext-Fallback.
- Profile auflisten, erstellen, ändern, löschen und zum Verbinden verwenden.
- Ausschließlich sichere PostgreSQL-Verbindungen:
- TLS verpflichtend,
- Zertifikatsprüfung,
- Hostnamenprüfung,
- optional zusätzliche lokale CA-Datei,
- kein unsicherer TLS-Modus,
- kein Zertifikats-/Hostname-Bypass,
- keine Klartextverbindung.
- Getrennte Azure-Management-Plane- und PostgreSQL-Data-Plane-Autorisierung.
- Azure-Sichtbarkeit darf nicht als PostgreSQL-Zugriffsberechtigung dargestellt werden.
- Permanente Anzeige des aktuellen Zielkontexts:
- Tenant,
- Subscription,
- Azure Server,
- Datenbank,
- Profil,
- PostgreSQL-Benutzer,
- TLS-/Verbindungsstatus,
- Kataloggeneration,
- Transaktionsstatus.
Tabellen und Schema
- Tabellen und Metadaten auflisten.
- Tabellendetails anzeigen:
- Spalten,
- Typen,
- Nullability,
- Defaults,
- Identity-Spalten,
- Generated-Spalten,
- Schlüssel,
- Constraints.
- Tabellen erstellen.
- Tabellen umbenennen.
- Tabellen in ein bestehendes Schema verschieben.
- Tabellen löschen.
- Kein implizites CASCADE bei geführtem Tabellen-Drop.
- Tabellen-Drop nur nach expliziter Bestätigung und exakter kanonischer Zielbezeichnung.
- Spalten:
- auflisten,
- hinzufügen,
- umbenennen,
- Typ ändern,
- Default setzen/entfernen,
- Nullability ändern,
- Identity verwalten,
- Generated-Ausdruck verwalten, soweit der Server dies unterstützt,
- löschen.
- Constraints:
- Primary Key,
- Unique,
- Foreign Key,
- Check,
- Exclusion.
- Constraints sollen erstellt, umbenannt, validiert und gelöscht werden können.
- DDL-Ausdrücke wie Defaults, Checks, Generated Expressions und Typkonvertierungen sollen als ausdrücklich markierte SQL-Ausdrücke sichtbar und bestätigungspflichtig sein.
- Geführte DDL-Operationen sollen transaktional ausgeführt werden, soweit PostgreSQL dies unterstützt.
- Abhängigkeiten vor destruktiven Tabellen-, Spalten- oder Constraint-Änderungen anzeigen und Drop blockieren, statt implizit Abhängigkeiten zu entfernen.
Zeilen-CRUD
- Tabelleninhalte paginiert lesen.
- Bevorzugt Keyset-Pagination über Primär- oder geeignete Unique Keys.
- Begrenzte Offset-Pagination als Fallback mit sichtbarer Instabilitätswarnung.
- Begrenzungen:
- maximal 200 Tabellenzeilen pro Seite,
- maximal 16 MiB gerenderte Daten pro Seite,
- maximal 10.000 Offset-Zeilen.
- Zeilen einfügen.
- Zeilen aktualisieren.
- Zeilen löschen.
- Insert/Update-Felder unterscheiden:
- unverändert,
- Default,
- NULL,
- Textwert.
- Werte werden parameterisiert übertragen; keine Benutzerwerte dürfen in SQL interpoliert werden.
- Generated- und IDENTITY ALWAYS-Spalten sind nicht regulär editierbar.
- Update/Delete sollen bevorzugt Primär- oder eindeutige Schlüssel verwenden.
- Ohne geeigneten Schlüssel soll ein kurzlebiger ctid-/xmin-Fallback mit sichtbarer Warnung verwendet werden.
- Zeilenmutationen müssen genau eine Zeile betreffen; null oder mehrere betroffene Zeilen sind ein Konflikt und dürfen nicht stillschweigend erfolgreich sein.
- Jede Zeilenänderung benötigt eine Bestätigung.
Rollen, Benutzer und Berechtigungen
- Rollen und Rollenattribute auflisten.
- Login- und Gruppenrollen anzeigen.
- Direkte und effektive Rechte getrennt anzeigen.
- Mitgliedschaften und Admin-Optionen anzeigen.
- Default Privileges anzeigen.
- Neue Login-Rollen erstellen.
- Sichere Standardattribute für neue Login-Rollen:
- kein Superuser,
- kein CREATEDB,
- kein CREATEROLE,
- keine Replication,
- kein BYPASSRLS,
- INHERIT.
- Rollenpasswörter erstellen oder zurücksetzen.
- Bestehende Passwörter niemals anzeigen oder wiederherstellen.
- Neue oder zurückgesetzte Zugangsdaten:
- Benutzername und Passwort als Einmal-Credential,
- genau einmal aus der Anwendung kopierbar,
- zeitlich begrenzt,
- danach aus dem kontrollierbaren Speicher entfernen.
- Clipboard-Schreiben soll das One-Time-Secret auch bei einem Clipboard-Fehler konsumieren.
- Rollenmitgliedschaften gewähren und entziehen, einschließlich Admin Option.
- Rollen löschen, wenn PostgreSQL dies ohne implizite Besitzübernahme oder Kaskade erlaubt.
- Kein DROP OWNED, kein REASSIGN OWNED, keine automatische Ownership-Übernahme und keine implizite Abhängigkeitsbereinigung.
- Rechte innerhalb dieser Matrix verwalten:
- Database: CONNECT, CREATE
- Schema: USAGE, CREATE
- Table: SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER
- Sequence: USAGE, SELECT, UPDATE
- Function: EXECUTE
- Rechte gewähren und entziehen.
- Default Privileges für zukünftige Tabellen, Sequenzen und Funktionen verwalten.
- Mehrdatenbank-Berechtigungspläne:
- vorab als vollständiger Plan anzeigen,
- alle Ziel-Datenbanken und Schritte anzeigen,
- pro Datenbank transaktional ausführen,
- Erfolg, Fehler und übersprungene Schritte separat darstellen,
- keine vorgetäuschte globale Atomarität,
- keine automatische Kompensation bereits erfolgreicher Datenbanken.
- Nicht grantierbare Berechtigungen mit Grund anzeigen und deaktivieren.
SQL-Arbeitsbereich
- Mehrzeiliger SQL-Editor.
- Ausführung einzelner vollständiger Statements oder ganzer SQL-Batches.
- Unterstützung mehrerer Statements und mehrerer Resultsets.
- Keine SQL-Allowlist oder künstliche SQL-Sandbox.
- Raw SQL wird mit den Rechten der verbundenen PostgreSQL-Rolle ausgeführt.
- Jede Raw-SQL-Ausführung benötigt eine explizite Bestätigung.
- Bestätigung zeigt Zielkontext, Datenbank, Rolle, Statement-/Batch-Information und SQL-Vorschau.
- SQL soll nicht umgeschrieben werden.
- Statement-Splitting muss Strings, Escape-Strings, quoted identifiers, Dollar-Quotes, Zeilenkommentare und verschachtelte Blockkommentare korrekt berücksichtigen.
- SQL-Fehler sollen keine sensiblen Serverdetails, Parameter oder Secrets anzeigen.
- Resultate sollen gestreamt und begrenzt dargestellt werden:
- maximal 1.000 Zeilen,
- maximal 16 MiB gerenderte Resultatdaten,
- maximal 64 KiB je Zelle,
- sichtbare Kennzeichnung ausgelassener und gekürzter Daten.
- Command Tags, Laufzeit, betroffene Zeilen, Resultsets und sichere SQLSTATE-Diagnosen anzeigen.
- Lang laufende SQL-Anweisungen abbrechen können.
- PostgreSQL-Cancel-Protokoll verwenden.
- Keine falsche Erfolgsmeldung nach Cancel, Timeout oder Verbindungsverlust.
- Katalog nach erfolgreicher freier SQL-Ausführung konservativ invalidieren.
- Keine persistente SQL-History.
- Keine persistente Speicherung von Resultsets oder SQL-Inhalten.
Transaktionen
- Explizite Transaktionen unterstützen:
- BEGIN,
- START TRANSACTION,
- COMMIT,
- ROLLBACK,
- Savepoints,
- Release Savepoint,
- Rollback To Savepoint.
- Workspace-Session bleibt für eine offene Transaktion gepinnt.
- Transaktionszustand soll serverautoritativer Zustand sein, nicht nur aus SQL-Text abgeleitet.
- Kein automatischer Commit.
- Commit soll separat bestätigt werden, wenn Änderungen dauerhaft werden.
- Bei Fehlern, Cancel oder Verbindungsverlust soll der Zustand als fehlgeschlagen oder unbekannt behandelt werden, nicht fälschlich als idle.
- Bei aktiver oder unklarer Transaktion müssen Datenbank-, Profil- oder Navigationswechsel blockiert werden, bis Commit, Rollback oder expliziter Disconnect gewählt wurde.
- Beim Beenden: Commit, Rollback oder Navigation abbrechen anbieten; niemals stillschweigend committen.
SQL-Completion
- Kontextbezogene Completion für:
- SQL-Keywords,
- Schemas,
- Tabellen,
- Spalten,
- Funktionen,
- Rollen.
- Completion aus aktuellem PostgreSQL-Katalog.
- Keine Completion innerhalb von Strings, Kommentaren oder Dollar-Quotes.
- Completion nur auf Basis einer aktuellen Kataloggeneration.
- Completion soll unbekannte PostgreSQL-/Extension-Syntax nicht blockieren.
- Begrenzung auf maximal 100 Vorschläge.
COPY
- Unterstützt ausschließlich:
- COPY ... FROM STDIN,
- COPY ... TO STDOUT.
- Nur lokale reguläre Dateien auf dem Client.
- Keine serverseitigen Dateipfade.
- Kein COPY PROGRAM.
- Keine Pipes.
- Keine URLs.
- Kein Cloud/Object Storage.
- COPY FROM:
- ausgewählte lokale Datei,
- Streaming mit Backpressure,
- keine vollständige Datei im Speicher.
- COPY TO:
- explizit ausgewählte lokale Zieldatei,
- temporäre Datei im Zielverzeichnis,
- erst nach vollständigem Erfolg atomar veröffentlichen,
- vorhandenes Ziel nur nach separater Überschreibbestätigung,
- exakte kanonische Pfadbestätigung für Überschreiben,
- bei Fehler/Cancel keine teilweise veröffentlichte Zieldatei,
- temporäre Ausgabe bestmöglich entfernen.
- COPY muss in die aktive SQL-Transaktion integriert sein.
- COPY-Bytes und Dateiinhalte dürfen nicht in Diagnosen, Events oder persistente Historie gelangen.
- COPY-Fortschritt soll sichtbar sein.
Bestätigungen und Sicherheitsmodell
- Jede extern wirksame schreibende Aktion benötigt eine Bestätigung:
- Azure-Datenbank Create/Drop,
- Profile Create/Edit/Delete,
- Keychain-Schreiben/-Löschen,
- Tabellen-, Spalten- und Constraint-DDL,
- Zeilen Insert/Update/Delete,
- Rollen- und Passwortoperationen,
- Mitgliedschaften,
- Grants/Revokes,
- Default Privileges,
- jede Raw-SQL-Ausführung,
- COPY,
- lokale Überschreibvorgänge,
- Clipboard-Credential-Schreibvorgänge.
- Bestätigungen sind einmalig, nicht wiederverwendbar und an Ziel, Plan, Kontext, Session, Kataloggeneration, SQL-Text, Formularwerte und Datei-/Pfadbindung gebunden.
- Destruktive Aktionen benötigen zusätzlich die exakte kanonische Zielbezeichnung:
- Datenbank,
- Tabelle,
- Spalte,
- Constraint,
- Rolle,
- Profil,
- bestehende COPY-Zieldatei.
- Kein Adapter-Schreibpfad darf die zentrale Bestätigungsrichtlinie umgehen.
- Azure CLI immer ohne Shell und ohne globales az account set.
- Secrets nie in:
- Profildateien,
- Events,
- Plänen,
- Logs,
- Diagnostik,
- SQL-Historie,
- Klartext-Umgebungsvariablen.
- TLS ist verpflichtend:
- Zertifikatsprüfung,
- Hostnamenprüfung,
- System-Trust,
- optional lokale zusätzliche CA,
- kein Trust-All,
- kein TLS-Bypass,
- keine Klartextverbindung.
- Geführte Datenwerte immer parameterisiert.
- Identifikatoren immer segmentweise validiert und gequotet.
- Freie SQL-/DDL-Ausdrücke sichtbar als SQL-Ausdrücke behandeln und vollständig bestätigen.
- Kein implizites CASCADE.
- Keine automatische Wiederholung von unklaren oder nicht-idempotenten Schreibvorgängen.
- Keine automatische Kompensation erfolgreicher Azure- oder PostgreSQL-Fachmutationen.
- Keine falsche Erfolgsmeldung bei Timeout, Cancellation, Connection Loss oder Azure-Propagation.
Betriebs-, UI- und Release-Anforderungen
- Reaktionsfähige TUI; Rendering und Tastatureingabe dürfen nicht auf Azure-, PostgreSQL-, Keychain-, Clipboard- oder Dateisystem-I/O warten.
- Begrenzte Event-Kanäle mit Backpressure.
- Stale Events anhand von Operation-ID, Ziel-/Session-/Kataloggeneration verwerfen.
- Permanente Anzeige von Tenant, Subscription, Server, Datenbank, Profil, PostgreSQL-Benutzer, TLS-Status, Kataloggeneration und Transaktionsstatus.
- Screens für:
- Server,
- Datenbanken,
- Profile/Connect,
- Tabellen,
- Rollen/Rechte,
- SQL/COPY,
- Diagnostics.
- Sichere Diagnostik mit Operation-ID, Kategorie, Retry-Hinweis und SQLSTATE, falls verfügbar.
- Release ausschließlich für macOS ARM64 und Windows x86_64.
- Gitea Actions:
- GitHub-kompatible Syntax,
- Repository-Variablen für Runner/API-Konfiguration,
- Secrets für Release-Credentials,
- native Validierung,
- Tests,
- Builds,
- versionsbasierte Releases,
- beide Zielartefakte,
- Prüfsummen,
- Release erst bei vollständiger Zielmatrix.
- Keine Release-Assets eines bereits veröffentlichten Releases still ersetzen.
- Keine Signierung oder Notarisierung im aktuellen Scope.
Nicht im Scope
- Flexible Server Lifecycle, Skalierung, Firewall, DNS, Private Endpoints, Azure RBAC, Backups, Restore oder PITR.
- Andere Datenbankengines oder PostgreSQL-Angebote.
- Datenbank Rename, Clone oder andere Eigenschaften außerhalb List/Create/Drop.
- Guided CRUD für Views, Materialized Views, Funktionen, Trigger, standalone Indizes, Extensions oder RLS-Policies.
- Rechte außerhalb der bestätigten Matrix.
- Server-/Programm-/Remote-/Cloud-COPY.
- Verteilte Transaktionen über mehrere Datenbanken oder Azure plus PostgreSQL.
- Persistente SQL-History, Secret-Synchronisierung, cloudbasierte Profile.
- Automatische Rücknahme bereits bestätigter und erfolgreicher Änderungen.
- Linux-Releases, Weboberfläche, Daemon, Telemetrie, Code-Signing oder Notarisierung.