Diese Seite beschreibt Calíope 1.5, die Version, die wir gerade bauen. Die 1.4 ist fertig und in der App-Review, und der Store liefert heute 1.3 auf dem Mac und 1.2 auf dem iPad. Das Changelog sagt, in welcher Version jede Funktion kam.
Fügt jedem Thema einen Button „In Calíope öffnen“ hinzu. Funktioniert nur mit installierter App.
Serverkonten samt ihren Rechten anlegen, bearbeiten und löschen.
Wo es zu finden ist: Workspace › Werkzeuge › Benutzer
Öffnen Sie Benutzer über die Navigationsleiste des Arbeitsbereichs. Das linke Panel listet alle Konten des Servers auf, die vom Server installierten separat gruppiert; das Suchfeld filtert nach Namen. Wählen Sie ein Konto aus, um seine Rechte zu laden.
Was rechts erscheint, hängt vom Motor ab, denn das Sicherheitsmodell ist nicht dasselbe. In MySQL und MariaDB ist ein Konto benutzer@host und Rechte werden auf vier Ebenen vergeben: Global, Datenbank, Tabelle und Routine. In PostgreSQL ist ein Konto eine Rolle, es gibt keinen Host, und statt der globalen Ebene erscheinen ihre Attribute, die nicht vergeben, sondern gesetzt werden. Was ein Motor nicht hat, wird nicht ausgegraut gezeichnet: es wird gar nicht gezeichnet.
Innerhalb jeder Karte sind die Kästchen nach Daten, Struktur, Routinen, Administration und Replikation gruppiert. Haken Sie an, was zutrifft, und drücken Sie Änderungen sichern; solange es ungesicherte Änderungen gibt, sagt es die Kopfzeile, und Änderungen verwerfen kehrt zum Stand auf dem Server zurück.
Drücken Sie Neuer Benutzer in der Leiste der Benutzerverwaltung. Geben Sie Namen und Passwort ein. Das Konto wird ohne Rechte angelegt; vergeben Sie sie danach.
Das Feld Host und die Auswahl der Authentifizierungsmethode erscheinen nur dort, wo der Motor sie hat. PostgreSQL hat weder das eine noch das andere: von wo eine Verbindung angenommen wird, entscheidet die Datei pg_hba.conf des Servers, und wie das Passwort verschlüsselt wird, entscheidet die Serverkonfiguration, nicht das Konto.
Wählen Sie das Konto im linken Panel aus und drücken Sie Löschen in der Kopfzeile. Ein Bestätigungsdialog zeigt, was entfernt wird. Die Aktion ist nicht umkehrbar.
Die vom Server installierten Konten erscheinen in einer eigenen Gruppe und lassen sich hier nicht löschen.
In PostgreSQL kann der Server sich weigern, und das ist kein Fehler von Calíope: eine Rolle, die Objekte besitzt oder Rechte hält, lässt sich nicht löschen, solange man sie ihr nicht entzieht. Calíope setzt keinDROP OWNED BY von sich aus ab, denn das würde Daten löschen, die niemand zu löschen verlangt hat. Entziehen Sie zuerst ihre Rechte — auch die von „alle Tabellen“, die zusätzlich ein Standardrecht hinterlassen — oder übertragen Sie, was sie besitzt.
Stichwörter: benutzer löschen, DROP USER, entfernen, widerrufen
Wo es zu finden ist: Benutzer › Benutzer bearbeiten
Wählen Sie das Konto im linken Panel aus und drücken Sie Bearbeiten in der Kopfzeile. Das Bearbeitungsformular öffnet sich.
Das Formular zeigt nur, was der Motor hat. In MySQL und MariaDB enthält es das Passwort, die Authentifizierungsmethode, die Kontosperre und die stündlichen Ressourcengrenzen. In PostgreSQL enthält es das Passwort und sonst nichts: es gibt keine Sperre — ein Konto wird geschlossen, indem man ihm das Attribut LOGIN nimmt, das auf seiner Karte steht — und keine stündlichen Grenzen, während die gleichzeitigen Verbindungen und das Ablaufdatum neben den Attributen bearbeitet werden.
Lassen Sie das Passwortfeld leer, wenn Sie nur die übrigen Einstellungen ändern wollen.
Weise granulare Rechte auf Ebene einer bestimmten DB, Tabelle oder Routine zu.
Wo es zu finden ist: Benutzer › Berechtigungsbaum
Jede Rechte-Ebene ist eine Karte mit ihrem Zähler der vergebenen Rechte und ihrem Schalter WITH GRANT OPTION:
- Rollenattribute — nur PostgreSQL. Das sind keine Rechte, sondern Eigenschaften der Rolle (LOGIN, SUPERUSER, CREATEDB…), die mit ALTER ROLE geschrieben werden. Gleichzeitige Verbindungen und Ablaufdatum stehen unten.
- Global — nur MySQL-Familie. Gelten für den ganzen Server (z. B. SUPER, PROCESS, REPLICATION SLAVE).
- Verbindung — nur PostgreSQL. Die Rechte der Cluster-Datenbank, auf die das Profil zeigt: CONNECT, CREATE und TEMPORARY. Sie entscheidet, ob das Konto sich überhaupt verbinden kann.
- Datenbank — über alle Objekte einer Datenbank (in PostgreSQL: eines Schemas).
- Tabelle — über eine bestimmte Tabelle.
- Routine — über eine gespeicherte Prozedur oder Funktion.
Innerhalb jeder Karte sind die Kästchen nach Kategorie gruppiert, mit Alle auswählen je Gruppe, und ALL PRIVILEGES steht hervorgehoben oben, weil es die ganze Ebene auf einmal vergibt.
Um eine fehlende Ebene hinzuzufügen, nutzen Sie Objekt hinzufügen in der unteren Leiste. Änderungen sichern führt die nötigen REVOKE und GRANT aus; lehnt der Server eines ab, erscheint neben der Taste ein Hinweis mit den Einzelheiten.
Warum dieser Bildschirm nicht wie der von MySQL aussieht und was jeder Teil bedeutet.
Wo es zu finden ist: Workspace › Werkzeuge › Benutzer
PostgreSQL kennt keine getrennten Benutzer und Gruppen: es kennt Rollen, und eine Rolle ist beides zugleich. Eine Rolle mit dem Attribut LOGIN kann sich anmelden; eine ohne dieses Attribut dient dazu, Rechte zu bündeln und sie anderen zu geben. Deshalb ändert der Bildschirm seine Form, und nicht aus einer Laune heraus.
Es gibt keinen Host. Ein Konto ist ein blosser Name. Von wo eine Verbindung angenommen wird, entscheidet pg_hba.conf, die zum Server gehört und nicht zum Konto — Calíope zeigt das hier also nicht und kann es nicht ändern.
Attribute sind keine Rechte.SUPERUSER, CREATEDB, CREATEROLE, REPLICATION, BYPASSRLS, INHERIT und LOGIN werden mit ALTER ROLE gesetzt, nicht mit GRANT vergeben. Beim Sichern schreibt Calíope sie alle: was Sie nicht ankreuzen, wird ausgeschaltet. Das macht den Bildschirm wahrhaftig — würde nur das Angekreuzte geschrieben, schaltete das Abwählen eines Kästchens es nicht aus und es käme beim nächsten Öffnen des Kontos von selbst zurück.
Mitgliedschaft ist transitiv. Gehört app zu leser und leser zu prüfer, dann hat app, was prüfer hat, ohne dass es ihr jemand vergeben hätte. Die Karte Mitglied von unterscheidet direkte von geerbten Mitgliedschaften und zeigt den Weg jeder einzelnen. Geerbte lassen sich hier nicht entfernen, und darum haben sie keine Taste: zu widerrufen wäre das Glied, und das gehört einer anderen Rolle.
PUBLIC ist keine Rolle: das sind alle. Es steht als weiteres Konto in der Liste, denn sonst sähe ein allen gewährtes Objekt privat aus. Standardmässig darf PUBLIC sich mit der Datenbank verbinden und jede Funktion ausführen.
Der Eigentümer hat alles über das Seine, und das erscheint nie als Vergabe. Eine frisch angelegte Tabelle hat im Katalog überhaupt keine Rechtezeile, und ihr Eigentümer kann trotzdem alles damit tun. Darum trägt die Kopfzeile die Marke „Eigentümer von N Objekten“ und diese Karten werden angekreuzt und ausgegraut gezeichnet: es gibt nichts zu vergeben und nichts zu entziehen.
„Auf alle Tabellen gewähren“ sind zwei Anweisungen. In MySQL deckt ON datenbank.* auch morgen angelegte Tabellen ab; hier braucht es zwei Befehle, die nicht dasselbe bedeuten: einer erreicht die jetzt vorhandenen Tabellen, der andere die künftigen. Der zweite deckt zudem nur jene ab, die das Konto anlegt, mit dem Calíope verbunden ist. Keiner von beiden kommt danach als Kästchen auf der Schema-Karte zurück, denn es sind keine Schema-Rechte. Die Taste daneben macht beide rückgängig, und sie wird gebraucht: solange das Standardrecht bestehen bleibt, lässt der Server das Konto nicht löschen.
Was es nicht gibt. Keine Kontosperre — man nimmt LOGIN weg —, keine stündlichen Grenzen — nur die Zahl gleichzeitiger Verbindungen —, keine Auswahl der Authentifizierungsmethode — das entscheidet der Server — und kein FLUSH PRIVILEGES: hier ist der Katalog die Quelle, und ein GRANT gilt bereits, wenn der Server antwortet.