Lese- und Schreibzugriffe der Aussteller schützen

Einführung

Fern Studio und Cedar Works bereiten sich auf einen kleinen Kunsthandwerksmarkt vor. Jeder Aussteller soll seine eigenen Anlieferungsanmeldungen in einer gemeinsamen PostgreSQL-Tabelle pflegen. Das Marktteam muss weiterhin alle sehen und Stände zuweisen können. Ein Filter in einem Clientbefehl ist zum Durchsehen nützlich, kann aber von einem Aussteller weggelassen werden; die Datenbank muss die Grenze durchsetzen.

Du speicherst Zeilenrichtlinien und wendest sie an. Anschließend verwendest du separate gewöhnliche Passwortanmeldungen, um tatsächliche Registrierungen abzuschließen. PostgreSQL und die auf diese Aufgabe begrenzten Konten sind vorbereitet. Du benötigst grundlegende Terminalnavigation sowie PostgreSQL SELECT/WHERE, INSERT, UPDATE und Tabellenkonzepte. Rollen, Zeilensicherheit, Richtlinienausdrücke, Transaktionen und die erforderliche Shell-Syntax werden vor der Verwendung erklärt. Python-Programmierung ist nicht erforderlich. Verwende durchgehend Terminal. Die Dauer von 95 Minuten ist eine Autorenschätzung einschließlich Lesen und gewöhnlicher Fehler, keine gemessene Abschlusszeit für Anfänger.

Arbeite unter /home/labex/project/exhibitor-desk. Verfasse read-access.sql und write-access.sql, ändere Zeilenrichtlinien auf fair.registrations und erstelle oder korrigiere nur die beiden später angegebenen neuen Registrierungen. Bewahre alle ursprünglichen Datensätze, Tabellenidentität und -definitionen, vorbereiteten Berechtigungen/Konten, Zugangsdaten, Werkzeuge und Dienste. Richtliniendateien müssen eigenständiges SQL sein: keine Shell-Befehle, Verbindungswechsel oder externen Einbindungen. Gleichwertige Richtliniennamen und korrekte Richtlinienanordnungen werden akzeptiert. Du bist der Kursoperator und kannst bewusst jedes vorbereitete Testkonto wählen; diese Übung schützt Datenbankidentitäten voreinander, keine Zugangsdaten vor dem sudo-Operator der VM. Sie implementiert keine Website-Authentifizierung und verspricht keinen Schutz vor jedem Informationsseitenkanal.

Sichtbarkeit begrenzen und das Marktteam arbeitsfähig halten

In diesem Schritt gibst du jedem Aussteller eine vollständige Sicht auf seine eigenen Registrierungen und hältst die ausstellerübergreifende Arbeit des Veranstalters verfügbar. Schreibzugriffe der Aussteller bleiben unverfügbar, bis der nächste Schritt ihre Schreibrichtlinien ergänzt.

Beginne in Terminal. cd wechselt das Verzeichnis; dieser absolute Pfad funktioniert unabhängig von deinem aktuellen Verzeichnis:

cd /home/labex/project/exhibitor-desk

./ führt ein Programm aus dem aktuellen Verzeichnis aus. Der vorbereitete Starter db authentifiziert eine tatsächliche PostgreSQL-Verbindung und führt psql, den PostgreSQL-Client, aus. Er filtert keine Zeilen und erzeugt keine erfundenen Ergebnisse. Liste seine Kontoaliase auf:

./db accounts

Die Aliase wählen diese separat vorbereiteten Logins:

Ein Alias ist eine Erleichterung für dich als Operator, keine Fern erteilte Datenbankberechtigung. Mit der bewussten Wahl von cedar verwendest du Cedars separate Zugangsdaten. Innerhalb einer Fern-Verbindung muss der Wechsel zu Cedar verboten bleiben.

-c übergibt eine Befehlszeichenfolge. Doppelte Anführungszeichen halten ihre Leerzeichen für die Shell zusammen. session_user identifiziert den authentifizierten Login; current_user identifiziert die Rolle, deren Berechtigungen die Anweisung aktuell verwendet. In diesen gewöhnlichen Verbindungen sollten sie übereinstimmen:

./db fern -c "SELECT session_user, current_user;"

Erwartet wird fern_studio in beiden Spalten. Lies zuerst Ferns bekannten normalen Datensatz. Die Kistenanzahl ist eine ganze Zahl; 0 ist ein bekannter Wert und bedeutet keine fehlende Registrierung:

./db fern -c "SELECT registration_id, owner_role, contact, crates, booth_label, fee_cents FROM fair.registrations WHERE registration_id = 'R101';"

R101 gehört Fern, hat den Kontakt Fern desk, 2 Kisten, Stand A1 und eine Gebühr von 1200 Cent. fair ist das Schema, das die Tabelle gruppiert. Diese ursprünglichen geschäftlichen Fakten müssen unverändert bleiben.

Lass nun den optionalen Clientfilter weg:

./db fern -c "SELECT registration_id, owner_role, crates FROM fair.registrations ORDER BY registration_id;"

Anfangs sieht Fern R101/R102 und Cedars R201/R202. WHERE owner_role = 'fern_studio' würde sie in dieser einen Abfrage verbergen, aber diese ungefilterte Abfrage nicht verhindern. Dasselbe Problem besteht für Cedar.

PostgreSQL hat zwei relevante Berechtigungsebenen. Ein GRANT erlaubt eine Operation auf einer Tabelle oder benannten Spalten; vorbereitete Berechtigungen erlauben diesen Benutzern bereits den Zugriff auf ihre erforderlichen Operationen. Row-Level Security, kurz RLS, entscheidet zusätzlich, welche Zeilen sie lesen oder ändern dürfen. RLS ohne passende Richtlinie zu aktivieren, verweigert standardmäßig Zugriff auf Zeilen; es erfindet nicht automatisch die Zugehörigkeitsregel.

Der editor besitzt diese Kurstabelle und kann Richtlinien ändern. Eigentümer umgehen RLS normalerweise, daher kann eine erfolgreiche Editorabfrage nicht beweisen, dass ein Aussteller eingeschränkt ist. Verwende den Editor zum Prüfen von Definitionen und gewöhnliche Konten zum Testen des Ergebnisses. \d ist ein psql-Beschreibungsbefehl, kein SQL:

./db editor -c "\d fair.registrations"

Die sechs Spalten sind registration_id, owner_role, contact, crates, booth_label und fee_cents. Eine neue Registrierung erhält standardmäßig Stand Pending und Gebühr 0. Vorbereitete Spaltenberechtigungen erlauben Ausstellern das Einfügen von ID/Besitzer/Kontakt/Kisten und das Aktualisieren von Besitzer/Kontakt/Kisten. Sie dürfen keine IDs, Stände oder Gebühren ändern, keine Zeilen löschen und die Tabelle nicht leeren. Die Richtlinie muss einen geänderten Besitzer trotzdem ablehnen, obwohl eine UPDATE-Berechtigung Zugriff auf die Besitzerspalte erlaubt.

Prüfe bestehende Richtlinien über PostgreSQLs Katalogsicht pg_policies:

./db editor -c "SELECT policyname, roles, cmd, qual, with_check FROM pg_policies WHERE schemaname = 'fair' AND tablename = 'registrations' ORDER BY policyname;"

legacy_open_access erlaubt allen Zugriff. Richtlinien sind normalerweise permissiv: Zutreffende Richtlinien werden mit OR kombiniert. Eine enge Richtlinie neben dieser breiten hinzuzufügen, würde das breite Ergebnis weiterhin erlauben. Entferne die alte Richtlinie als Teil der Änderung.

Der Ausdruck USING einer Richtlinie entscheidet, ob eine bestehende Zeile sichtbar ist. owner_role = current_user vergleicht den Besitzer der Zeile mit der tatsächlichen Datenbankidentität. FOR SELECT begrenzt diese Richtlinie auf Lesen. Der Veranstalter benötigt eine separate Richtlinie, begrenzt durch TO fair_team, die seine eigenen berechtigten Operationen auf allen Zeilen erlaubt; true bedeutet, dass jede Zeile für diese benannte Rolle besteht.

Speichere die erste Migration. cat > read-access.sql schreibt den folgenden Text in die Datei und ersetzt eine ältere Kopie. <<'SQL' beginnt ein Here-Dokument: Die Markierung in Anführungszeichen bewahrt das eingeschlossene SQL wörtlich, bis SQL allein in einer Zeile erscheint. BEGIN und COMMIT machen diese Richtlinienänderung zu einer Transaktion, sodass die Anweisungen gemeinsam bestätigt oder bei einem Fehler zurückgerollt werden. DROP POLICY IF EXISTS erlaubt außerdem, diese Migration zu korrigieren und erneut auszuführen:

cat > read-access.sql <<'SQL'
BEGIN;
ALTER TABLE fair.registrations ENABLE ROW LEVEL SECURITY;
DROP POLICY IF EXISTS legacy_open_access ON fair.registrations;
DROP POLICY IF EXISTS own_read ON fair.registrations;
DROP POLICY IF EXISTS organizer_access ON fair.registrations;
CREATE POLICY own_read ON fair.registrations
  FOR SELECT TO fern_studio, cedar_works
  USING (owner_role = current_user);
CREATE POLICY organizer_access ON fair.registrations
  TO fair_team USING (true) WITH CHECK (true);
COMMIT;
SQL

Wartet die Shell weiterhin, weil du die Endmarkierung ausgelassen hast, gib SQL allein ein. Lies die gespeicherte Datei vor ihrer Ausführung:

cat read-access.sql

-f weist psql an, Befehle aus einer Datei zu lesen. Wende sie als auf diese Aufgabe begrenzter Tabelleneigentümer an:

./db editor -f read-access.sql

Erwarte BEGIN-, ALTER-TABLE-, DROP-POLICY-, CREATE-POLICY- und COMMIT-Meldungen. Ein Hinweis, dass einer deiner neuen Richtliniennamen noch nicht existierte, ist harmlos. Der Starter aktiviert ON_ERROR_STOP: Ein Syntaxfehler in einer Datei stoppt die Ausführung mit psql-Status 3. Die schließende Verbindung rollt eine unvollendete Transaktion zurück. Korrigiere die Datei und führe sie erneut aus; setze die VM nicht zurück. Verwende bei einem Dateinamen-/Pfadfehler das absolute cd, führe ls aus, lies den tatsächlichen Dateinamen und versuche es erneut. Keine ursprüngliche Zeile muss gelöscht oder neu erstellt werden.

Prüfe mit jeder gewöhnlichen Identität die vollständige erlaubte Menge:

./db fern -c "SELECT registration_id, owner_role, crates FROM fair.registrations ORDER BY registration_id;"

./db cedar -c "SELECT registration_id, owner_role, crates FROM fair.registrations ORDER BY registration_id;"

Fern sieht R101/R102 mit Anzahlen 2/0. Cedar sieht R201/R202 mit Anzahlen 3/1. Der Veranstalter sieht weiterhin alle vier Originale:

./db organizer -c "SELECT registration_id, owner_role, booth_label FROM fair.registrations ORDER BY registration_id;"

Dies ist ein beabsichtigter Zwischenzustand: Aussteller haben eine SELECT-Richtlinie, aber noch keine INSERT-/UPDATE-Richtlinie. Lass ihre vorbereiteten Berechtigungen unverändert. Führe die Ergebnisprüfung aus; sudo erlaubt der vorbereiteten Prüfung, geschützten Zustand zu lesen. Sie liest die aktuellen Geschäftsdaten und testet Richtlinien-SQL auf entbehrlichen Daten, ohne deine fehlende Arbeit zu ergänzen:

sudo python3 /opt/labex-exhibitors/verify.py visibility

Erwarte die Bestätigung, dass beide Konten ihre eigenen Datensätze sehen und der Veranstalter arbeitsfähig bleibt. Ergänze als Nächstes die separaten Regeln für vorgeschlagene Schreibzugriffe.

Bestehende Zeilen und vorgeschlagene Werte prüfen

In diesem Schritt erlaubst du Ausstellern, eigene Registrierungen hinzuzufügen und zu aktualisieren, ohne Datensätze für einen anderen Besitzer zu erstellen oder zu übertragen. Beginne in Terminal unter /home/labex/project/exhibitor-desk.

Eine SELECT-Richtlinie allein erlaubt kein INSERT. Eine Schreibrichtlinie muss zwei Zeitpunkte betrachten. Für UPDATE wählt USING die bestehenden Zeilen aus, die die Rolle ändern darf; WITH CHECK prüft die vorgeschlagene neue Zeile. Für INSERT gibt es keine alte Zeile, daher verwendet seine Richtlinie nur WITH CHECK. In beiden Fällen muss der vorgeschlagene Besitzer current_user entsprechen.

Speichere die Schreibmigration im selben Here-Dokument-Format mit Anführungszeichen. Sie ergänzt Richtlinien zur bereits durch read-access.sql geschützten Tabelle:

cat > write-access.sql <<'SQL'
BEGIN;
DROP POLICY IF EXISTS own_insert ON fair.registrations;
DROP POLICY IF EXISTS own_update ON fair.registrations;
CREATE POLICY own_insert ON fair.registrations
  FOR INSERT TO fern_studio, cedar_works
  WITH CHECK (owner_role = current_user);
CREATE POLICY own_update ON fair.registrations
  FOR UPDATE TO fern_studio, cedar_works
  USING (owner_role = current_user)
  WITH CHECK (owner_role = current_user);
COMMIT;
SQL

Lies sie und wende sie dann als Editor an:

cat write-access.sql

./db editor -f write-access.sql

Erwarte, dass die beiden CREATE-POLICY-Anweisungen per Commit bestätigt werden. Die Datei zu korrigieren und erneut auszuführen, ersetzt nur diese benannten Schreibrichtlinien; es setzt keine Registrierungen zurück. Wenn du von deinen gespeicherten Richtliniendateien aus neu beginnst, wende zuerst read-access.sql und dann write-access.sql an.

Gleichwertige Richtlinienanordnungen können funktionieren. Eine ALL- oder UPDATE-Richtlinie nur mit USING verwendet diesen Ausdruck implizit für ihr fehlendes WITH CHECK; das Weglassen dieser Klausel ist nicht automatisch ein Fehler. Hier machen separate Befehlsrichtlinien jede Aufgabe ausdrücklich. Entscheidend ist das Verhalten jeder erlaubten und verbotenen Operation, nicht die Richtliniennamen oder exakte Schreibweise.

Erprobe zuerst einen berechtigten Schreibzugriff, ohne Testdaten zu hinterlassen. BEGIN startet eine Transaktion. RETURNING zeigt die von INSERT/UPDATE tatsächlich gespeicherte Zeile. ROLLBACK verwirft die Änderungen der Transaktion und lässt die vier Originale intakt:

./db fern -c "BEGIN; INSERT INTO fair.registrations (registration_id, owner_role, contact, crates) VALUES ('TRY-FERN', 'fern_studio', 'Loading test', 0); UPDATE fair.registrations SET crates = 2 WHERE registration_id = 'TRY-FERN' RETURNING registration_id, owner_role, crates; ROLLBACK;"

Erwarte TRY-FERN, Besitzer fern_studio und 2 Kisten, gefolgt von ROLLBACK. Die normale Einfügung akzeptiert eine tatsächliche 0, und das Update funktioniert; eine Regel, die jeden Schreibzugriff verweigert, würde diese Anforderung verletzen.

Teste nun eine verborgene bestehende Zeile. Diese Anweisung muss als Befehl erfolgreich sein und dabei keine erlaubte Zeile zum Aktualisieren finden:

./db fern -c "UPDATE fair.registrations SET contact = 'Wrong contact' WHERE registration_id = 'R201' RETURNING registration_id;"

Erwarte keine zurückgegebene Zeile und UPDATE 0. R201 gehört Cedar. Ein Ergebnis mit null Zeilen ist Zeilenfilterung, kein Verbindungsfehler oder Datenbankfehler.

Die nächsten beiden Befehle sind erwartete SQL-Fehler. Beide schließen den Test in eine Transaktion ein: Würde eine falsche Richtlinie ihn versehentlich akzeptieren, würde das abschließende ROLLBACK ihn trotzdem verwerfen. Stoppt ein Fehler den Befehl vor ROLLBACK, verwirft das Schließen der Verbindung ebenfalls seine unvollendete Transaktion.

Versuche, einen Cedar gehörenden Datensatz zu erstellen, während du als Fern authentifiziert bist. Lass RETURNING absichtlich aus: Eine SELECT-Richtlinienprüfung zurückgegebener Zeilen darf nicht die Schreibregel für vorgeschlagene Zeilen ersetzen:

./db fern -c "BEGIN; INSERT INTO fair.registrations (registration_id, owner_role, contact, crates) VALUES ('TRY-FOREIGN', 'cedar_works', 'Wrong owner', 1); ROLLBACK;"

Erwartet wird new row violates row-level security policy. $? ist der Status des unmittelbar vorangehenden Shell-Befehls; gib ihn aus, bevor du etwas anderes ausführst:

echo $?

Erwarte Status 1 für diesen fehlgeschlagenen SQL-Befehl mit -c. Status 2 mit einem Verbindungs-/Authentifizierungsfehler ist ein anderer Fehler und beweist nicht, dass die Zeilenrichtlinie gewirkt hat. Der Starter wählt bei jedem Aufruf die vorbereiteten Zugangsdaten; verwende ./db accounts und versuche den dokumentierten Alias erneut, statt Zugangsdaten-Dateien zu bearbeiten.

Versuche als Nächstes, den Besitzer von Ferns sichtbaren Zeilen auf Cedar zu ändern. Das konstante UPDATE hat weder WHERE noch RETURNING, das eine Tabellenspalte liest. Dies erreicht direkt die Prüfung vorgeschlagener Zeilen; die umgebende Transaktion hält selbst einen versehentlich akzeptierten Test rückgängig machbar:

./db fern -c "BEGIN; UPDATE fair.registrations SET owner_role = 'cedar_works'; ROLLBACK;"

echo $?

Erwarte erneut den Zeilensicherheitsfehler und Status 1. Leite daraus nicht ab, dass nur Updates mit RETURNING Schutz benötigen: Erlaubtes SQL kann es weglassen.

Spaltenberechtigungen bieten eine andere Grenze. Ein Aussteller darf eigenen Kontakt/Anzahl ändern, doch das Marktteam weist Stände und Gebühren zu. Dieser versuchte Standwechsel muss selbst für Ferns eigene Zeilen einen Tabellenberechtigungsfehler erzeugen:

./db fern -c "BEGIN; UPDATE fair.registrations SET booth_label = 'WRONG'; ROLLBACK;"

Erwartet wird permission denied for table registrations, kein Richtlinienfehler für eine vorgeschlagene Zeile. Ebenso kann eine Fern-Verbindung nicht allein durch Benennen dieser Rolle zu Cedar werden:

./db fern -c "SET ROLE cedar_works;"

Erwartet wird permission denied to set role. Vorbereitete Aussteller sind gewöhnliche Logins ohne kontenübergreifende Mitgliedschaft, Tabelleneigentum oder BYPASSRLS. Eine frei gewählte Anwendungseinstellung zu ändern, würde keinen anderen Login authentifizieren; die Richtlinie vergleicht die tatsächliche Datenbankrolle.

Bestätige, dass die rückgängig gemachten Tests die ursprünglichen geschäftlichen Fakten intakt gelassen haben:

./db organizer -c "SELECT registration_id, owner_role, contact, crates, booth_label, fee_cents FROM fair.registrations ORDER BY registration_id;"

Die ursprünglichen vier Zeilen, Kontakte, Anzahlen, Stände und Gebühren müssen ihren Anfangswerten entsprechen. Führe die Prüfung der Schreibgrenze aus:

sudo python3 /opt/labex-exhibitors/verify.py writes

Sie prüft beide gewöhnlichen Identitäten, berechtigte Schreibzugriffe, geänderte Datenbestände, besitzerfremde Schreibzugriffe und Veranstalterzugriff. Ein vollständiges Bestehen bedeutet, dass du die geschützte Tabelle nun für normale Arbeit verwenden kannst.

Registrierungen über die geschützten Konten abschließen

In diesem Schritt verwendest du die funktionierenden Berechtigungen, um zwei tatsächliche Anlieferungsanmeldungen vorzubereiten. Beginne in Terminal unter /home/labex/project/exhibitor-desk. Diese beiden neuen Datensätze sind die einzigen Geschäftszeilen, die du ergänzen oder korrigieren darfst; bewahre jede ursprüngliche Zeile.

Fern beginnt eine neue Registrierung mit der bekannten Kistenanzahl 0. Die bereitgestellten Standardwerte lassen ihren Stand bei Pending und die Gebühr bei 0, bis der Veranstalter sie zuweist:

./db fern -c "INSERT INTO fair.registrations (registration_id, owner_role, contact, crates) VALUES ('R301', 'fern_studio', 'Fern loading', 0) RETURNING registration_id, owner_role, contact, crates, booth_label, fee_cents;"

Erwarte R301, fern_studio, Fern loading, 0, Pending, 0. Dies ist ein tatsächliches per Commit bestätigtes INSERT, anders als die früheren Transaktionstests. Eine Wiederholung würde einen Fehler wegen eines doppelten Schlüssels erzeugen; es ist kein idempotenter Erstellungsbefehl.

Setze die abschließende Kistenanzahl durch ein gezieltes gewöhnliches Update auf vier:

./db fern -c "UPDATE fair.registrations SET crates = 4 WHERE registration_id = 'R301' RETURNING registration_id, owner_role, crates;"

Cedar erstellt seine eigene neue Registrierung mit einer Kiste:

./db cedar -c "INSERT INTO fair.registrations (registration_id, owner_role, contact, crates) VALUES ('R302', 'cedar_works', 'Cedar freight', 1) RETURNING registration_id, owner_role, crates;"

Erwarte R302, cedar_works und 1. Jeder Aussteller hat nun drei sichtbare Datensätze, einschließlich seiner beiden Originale.

Die eigene gewöhnliche Identität des Veranstalters weist jedem neuen Datensatz den vereinbarten Stand und die Gebühr zu. Gebühren sind ganze Centbeträge; diese bereitgestellten Beträge sind Szenariofakten, keine Steuer- oder Buchhaltungsberechnung:

./db organizer -c "UPDATE fair.registrations SET booth_label = 'C3', fee_cents = 1800 WHERE registration_id = 'R301' RETURNING registration_id, booth_label, fee_cents;"

./db organizer -c "UPDATE fair.registrations SET booth_label = 'D2', fee_cents = 600 WHERE registration_id = 'R302' RETURNING registration_id, booth_label, fee_cents;"

Erwarte R301/C3/1800 und R302/D2/600. Diese Arbeit verwendet fair_team, nicht den Tabelleneigentümer; eine Umgehung durch den Eigentümer würde nicht belegen, dass die Veranstalterrichtlinie nutzbar bleibt.

Lies die abschließenden vollständigen Datensätze über jeden Aussteller:

./db fern -c "SELECT registration_id, owner_role, contact, crates, booth_label, fee_cents FROM fair.registrations ORDER BY registration_id;"

./db cedar -c "SELECT registration_id, owner_role, contact, crates, booth_label, fee_cents FROM fair.registrations ORDER BY registration_id;"

Fern sieht R101/R102/R301 mit der neuen Anzahl 4 für R301, Stand C3 und Gebühr 1800. Cedar sieht R201/R202/R302 mit der neuen Anzahl 1 für R302, Stand D2 und Gebühr 600. Ursprüngliche Datensätze müssen unverändert bleiben.

Wiederholst du versehentlich ein INSERT, prüfe diesen benannten neuen Datensatz mit dem entsprechenden Konto. Existiert er bereits, verwende ein gezieltes UPDATE seines Kontakts/seiner Anzahl, statt ihn zu löschen oder die Datenbank zurückzusetzen. Ferns neuer Datensatz kann zum Beispiel mit UPDATE fair.registrations SET contact = 'Fern loading', crates = 4 WHERE registration_id = 'R301'; korrigiert werden. Korrigiere nur die benannten neuen Datensätze; führe die gezielte Stand-/Gebührenzuweisung des Veranstalters erneut aus, falls du dort einen Fehler gemacht hast. Auch die gespeicherten Migrationen können korrigiert und erneut angewendet werden, ohne Daten neu zu erstellen.

Führe die abschließende Ergebnisprüfung aus:

sudo python3 /opt/labex-exhibitors/verify.py business

Erwarte die Bestätigung, dass beide neuen Registrierungen mit korrekter Zugehörigkeit, Anzahlen, Ständen und Gebühren bereit sind. Du hast wiederverwendbares Richtlinien-SQL und ein gemeinsames Register, das gewöhnliche Aussteller und der Veranstalter tatsächlich verwenden können. Die unabhängige Challenge wendet dieselben Grenzen auf ein anderes Register von Kunsthandwerkern an.

Zusammenfassung

Du hast Tabellen-/Spaltenberechtigungen von der Zugehörigkeit von Zeilen getrennt, eine breite permissive Richtlinie entfernt und sowohl bestehende Zeilen als auch vorgeschlagene Schreibzugriffe über tatsächliche gewöhnliche Logins geprüft. Zwei neue Registrierungen und ihre vom Veranstalter zugewiesenen Stände funktionieren nun, ohne Datensätze eines anderen Ausstellers offenzulegen oder zu ändern.

Die Grenze ist die authentifizierte Datenbankidentität. Tabelleneigentümer und Administratoren bleiben vertrauenswürdig, und diese Übung bietet weder Website-Anmeldung noch eine Garantie gegen jeden Datenbankseitenkanal.