SQLite Data Studio: Verbindungen
Zurück: SQLite Data Studio
Eine benannte Verbindung sagt dem Studio, welche Datenbank es öffnen darf – Routinen, Berechtigungen und eingebettete Abfragen hängen alle daran.
[Live]
Konzept
Benannte Verbindungen werden im Admin-Bereich „Verbindungen“ verwaltet und als JSON unter
conf/wksqliteds.connections.json gespeichert (atomarer Schreibvorgang: Temp-Datei +
Rename, .bak vor jedem Überschreiben). Ein Datensatz: name, driver, host,
port, database, dbfile (SQLite/Access), user, secret (Referenz, nie
Klartext), charset, options.
Secret-Schemata
Das Feld secret enthält kein Passwort, sondern einen Verweis darauf. Ist
Vault (wkvault) installiert, löst dessen SecretRef den
Verweis auf – dieselbe Definition, die für alle Pakete des Baukastens gilt:
| Schema | Bedeutung | Einsatz |
|---|---|---|
| (leer) | kein Passwort | SQLite-Datei, vertrauter Socket |
vault:<id> | Eintrag im Vault-Tresor (Service vault.secrets) | empfohlen |
env:<VAR> | aus der Prozessumgebung | Produktion ohne Tresor |
file:<pfad> | Datei unterhalb des in Vault eingestellten Verzeichnisses (file_root) | nur mit installiertem Vault |
enc:<base64> | AES-verschlüsselt mit dem Instanz-Salt | Einzelhost-Interim |
plain:<base64> | nur base64 | nur Dev/Test |
env:, enc: und plain:
funktionieren unverändert, vault: wird mit dem Hinweis abgewiesen, dass kein Tresor
verfügbar ist (file: kennt dieser Rückfall nicht). Eine Verbindung mit vault:-Verweis
funktioniert auf einer Installation ohne Vault also nicht – vor dem Übertragen der
Konfiguration auf eine andere Installation prüfen, ob Vault dort installiert ist.
Der Admin-Bereich zeigt nie den Secret-Klartext, nur eine Kurzbeschreibung des Schemas
(ConnectionManager::describeSecret()) – auch im Auxbar-AJAX-Endpunkt.
„Connect to…“
Eine neue SQLite-Verbindung lässt sich ohne manuelle Pfadeingabe anlegen: Auswahl direkt
aus DokuWikis Medien-Namespace-Baum (nur .sqlite3-Dateien, ACL-geprüft – der Baum zeigt
ausschließlich Namespaces, die das aktuelle Konto tatsächlich lesen darf). Betriebshinweis:
.sqlite3 ggf. in conf/mime.local.conf als Upload-Mimetype freischalten, sonst
verweigert DokuWikis Medien-Upload die Datei.
Migration von der Altdatei
Vor der Umbenennung des Plugins (wvdsdwmsqlite → wksqliteds, 2026-07-14) lag der
Speicherort unter conf/wvdsdwmsqlite.connections.json. Eine einmalige, automatische
Übernahme läuft beim ersten load() nach der Umbenennung: existiert die neue Datei noch
nicht, aber die alte schon, wird der Inhalt kopiert (nicht verschoben) – die Altdatei
bleibt als manueller Rollback-Punkt liegen. Sobald die neue Datei einmal existiert (egal ob
migriert oder frisch gespeichert), wird die Altdatei nie wieder konsultiert.
Backend-Treiber
| Backend | Treiber-Schlüssel | Windows-Voraussetzung |
|---|---|---|
| SQLite | sqlite | – |
| MySQL/MariaDB | mysql | pdo_mysql |
| PostgreSQL | pgsql | pdo_pgsql |
| SQL Server | sqlsrv | Microsoft ODBC Driver for SQL Server |
| MS Access | access (intern odbc) | ACE/Jet-ODBC-Treiber „Microsoft Access Driver (*.mdb, *.accdb)“ + pdo_odbc |
Sicherheit
- Secrets nie im Klartext gespeichert, nie in Fehlermeldungen – nur die Referenz-Zeichenkette (Schema + ID/Variable) landet in
connections.json. - Verbindungsverwaltung (anlegen/bearbeiten/löschen/testen) erfordert die Fähigkeit
adminder Berechtigungs-Matrix – dieselbe Fähigkeit, die auch den Berechtigungs-Matrix-Dialog selbst freischaltet (beide gelten als „administrative Verwaltung“, nicht als normale Studio-Nutzung). - Löschen einer Verbindung läuft über einen echten Zwei-Schritt-Bestätigungsdialog (kein natives
confirm()) – Details zum Muster: Studio → Dialog-Katalog.
Verwandte Themen
- SQLite Data Studio: Admin-Oberfläche – Objekt-Explorer zeigt alle Verbindungen als Wurzelknoten
- SQLite Data Studio: Berechtigungen – verbindungsscope-spezifische Fähigkeits-Regeln