Benutzerverwaltung

[Mathias Berg]

Hallo,

ich bin gerade dabei eine Delphi 5-Anwendung mit Datenzugriff auf Paradox zu Interbase 6.01 umzusiedeln. In der Anwendung ist eine Benutzer- u. Berechtigunsverwaltung implementiert (-> FatClient -> db-unabhängig). Daher dachte ich mir alle Clients unter dem selben db-user zugreifen zu lassen und mir die ganze Geschichte "wie lege ich über Interbase-API neue Benutzer an" zu sparen. Kommt da der Interbase-Server ins Straucheln oder ist das Konzept aus anderen Gründen unglücklich? Wie kann ich dann immernoch feststellen wieviele User momentan eingeloggt sind?

Vielen Dank für eure Statements (Rat/Kritik) im voraus.

Gruß

Mathias

P. S.: Frohe Ostern :-)

[Andreas Kosch]

Hallo,

es ist dem InterBase letztendlich egal, wieviele Sessions ein Benutzer gleichzeitig offen hat, daher können alle Clients mit dem gleichen Benutzernamen (SYSDBA?) darauf zugreifen. Bei der Anzeige der aktiven Sessions taucht dieser Benutzername dann ebenfalls mehrfach auf

[Thomas Steinmaurer]

Hallo Mathias,<br><br>

wie bereits Andreas erwähnt hat, ist es durchaus möglich, dass sich mehrere Clients mit einem Benutzer anmelden können. Dies ist vermutlich auch die am häufigsten verwendete Form, um von einer Delphi-Anwendung (TDatabase, TIBDatabase) heraus mit einer IB/Firebird-Datenbank zu arbeiten, da sie sehr schnell zu realisieren ist.<br><br>
Ich bin vor ca. einem Jahr vor einer ähnlichen Entscheidung gestanden und habe mich trotz Mehraufwand für die umfangreichere Variante entschieden (Verwendung von "echten" IB-Benutzer). Folgende Fragestellungen (Anforderungen) sind damals aufgetaucht:<br><br>
1.) Datensicherheit: <br><br>
Die Verwendung von "SYSDBA" bei eigenen Applikationen würde ich auf jeden Fall vermeiden, da hier einige ungewollte Probleme bzgl. Datensicherheit auftreten können. Da ja IB/Firebird Open-Source ist, kann es durchaus vorkommen, dass eine IB/Firebird-basierende Applikation in einer Umgebung installiert werden soll, wo bereits IB/Firebird von einer anderen Firma als Client/Server-Datenbank eingesetzt wird. D.h. diese Firma wird vermutlich auch das Password von SYSDBA bei der Erstinstallation geändert haben und dieses Password Dir vermutlich nicht so einfach bekanntgeben. Weiters hat diese Firma (theoretisch) VOLLEN Zugriff (Metadaten, Daten, ...) auf Deine Datenbank. <br>
=> Immer einen eigenen Benutzer (MYADMIN) als Besitzer der DAtenbank und Datenbankobjekte verwenden. D.h. Tabellen, Views, Stored Procedures, ... immer mit 'MYADMIN' erzeugen! Verwendet man für jede DDL-Anweisung den Benutzer 'MYADMIN', so kann man getrost mit INSERT INTO RDB$ROLES VALUES ('SYSDBA', 'MYADMIN') den Benutzer 'SYSDBA' von der DAtenbank ausschliessen (kann sich nicht mehr anmelden!).<br><br>
2) Protokollieren von Datenmanipulierenden Operationen<br><br>
IB/Firebird stellt das Schlüsselwort 'USER' zur Verfügung, um in Triggern und Stored Procedures, den aktuell angemeldeten IB-Benutzer zu ermitteln. Will man nun einen Mechanismus (Logging) entwickeln, der ein zentralisiertes (in der Datenbank ohne zusätzlichen Code in der Client(Delphi)-Applikation) Protokollieren von Daten-Änderungen realisiert, so kann dies nur mit "echten" IB-Benutzern realisiert werden, da ja sonst immer 'SYSBDA' od. 'MYADMIN', ... als Benutzer erkannt wird, der Daten in der Datenbank geändert hat. Verwendet man eigene IB-Benutzer, so können Fragestellungen wie: "Wer hat den Preis in der Tabelle Artikel verändert?", ... beantwortet werden.<br><br>
3) Zugriff auf die Datenbank mit Tools von Drittherstellern<br><br>
Hier ist zum Beispiel ein Reporting Tool (Crystal Reports; Zugriff über ODBC mit SYSDBA/? :-)) gemeint. Applikationen aus der MS Office Familie, ... Hier sollte der Benutzer beim Zugriff über ODBC nicht unbedingt SYSDBA/? eingeben müssen :-).<br><br>

Das sind nur ein paar Dinge, die mir rasch zu diesem Thema eingefallen sind. <br><br>
Punkt 1) ist für mich bei einer Neuentwicklung absolut notwendig.<br>
Punkt 2) benötigt eine "IB-konforme" Benutzerverwaltung in der Client-Applikation. Vermutlich müssen hierzu Bearbeiter in einer Tabelle BEARBEITER mit den IB-Benutzer synchron gehalten werden (über die Interbase-API; IBX bietet hierzu die Komponente TIBSecurityService an; funktioniert allerdings nur mit IB6/Firebird)<br>
Punkt 3) setzt ein Security-Konzept unabhängig von der Client-Applikation, also in der Datenbank voraus. Ein Security-Konzept auf Datenbankebene lässt sich am besten mit eigenen IB-Benutzer + ROLES + VIEWS realisieren. VIEWS gerade dann, wenn es sich um Auswertungen handelt.<br><br>

Thoma

[Mathias Berg]

Hallo Thomas u. Andreas,

vielen Dank für die Antworten.
Gut ist schon mal, dass es keine Komplikationen gibt, wenn man alle Clients unter dem gleichen User laufen lässt.
Andreas, zu deinen Tipps: Die zu deinen Vorschlägen passenden Problemen sind mir die ganze Zeit schon im Kopf rumgeschwirrt :-)

Also für mich bedeutet das letztendlich, dass ich insbesondere dein Punkt 1 sofort berücksichtigen muss. Die anderen kann ich dann später nachschieben; sind ja für den Anwender transparent.

Mit deiner Vermutung zu Punkt 2 hast du recht: die Benutzer werden
in einer Tabelle verwaltet. Aber ich würde den Sync-Mechanismus gerne auf der DBA-Seite haben. Ist das machbar?

Jetzt habe ich erst mal mit der Datenübernahme zu tun; insbesondere wie ich die Autoinc-Felder mit Trigger bzw. Generator nachbilde. Die haben die Funktion eines Primärschlüssels; wurden aber dummerweise nicht so konfiguriert. Gibt es eine Möglichkeit per SQL zu einer Tabelle nachträglich eine Spalte als Primärschlüssel festzulegen?

Gruß Mathia

[Andreas Kosch]

Hallo,

wenn die Anwendung mit Delphi 5 entwickelt wird, erfolgt der Zugriff sicherlich über die <b>IBX</b>-Komponenten (InterBase Express). Und dort steht für <b>TIBDataSet</b> eine Option für die automatische Vergabe den INTEGER-Primärschlüsselwerten zur Verfügung (GeneratorField). In der InterBase-Datenbank muss man nur noch einen Generator pro Tabelle anlegen, den Rest macht IBX automatisch.

Ein Primärschlüssel kann auch nachträglich deklariert werden. Angenommen, es wird die folgende Tabelle angelegt, wobei sich hinter der eigenen Domain <i>TID</i> die Deklaration <i>CREATE DOMAIN TID AS INTEGER NOT NULL;</i> verbirgt:
<pre>
CREATE TABLE Redakteur (
RedakteurID TID,
Loginname TLoginname,
Nachname TNachname,
Vorname TVorname,
eMail TeMail,
Telefon TTelefon,
Bemerkung TBemerkung);
</pre>
In diesem Fall kann man im Nachhinein über eine ALTER TABLE-Anweisung einen Constraint für den Primärschlüssel hinzufügen:
<pre>
ALTER TABLE Redakteur
ADD CONSTRAINT PK_Redakteur PRIMARY KEY(RedakteurID);
</pre&gt

[Mathias Berg]

Hallo,

Danke für Hilfe. Aber was tun, wenn RedakteurID nicht als not null definiert ist?

Gruß
Mathia

[Wolfhard Kupfer]

Hallo,

ein primary/unique key muss not null sein (vgl. http://community.borland.com/article/0,1410,26665,00.html )

Best Regards,
Wolfhar

[Wolfhard Kupfer]

> [..] mir die ganze Geschichte "wie lege ich über
> Interbase-API neue Benutzer an" zu sparen. [..]

In dem Punkt wird die API doch ganz gut durch IBX gekapselt (<b>TIBSecurityService</b>).

Wolfhar

[Mathias Berg]

Hi Wolfhard,

genau da liegt das Problem: die betreffende Spalte wurde beim create der Tabelle gerade nicht als not null definiert. Meine Frage ist jetzt ob ich das nachträglich (z. b. über eine constraint) hinkriege.

Gruß
Mathia

[Torsten Grundke]

Hallo Mathias,

folgende SQL-Anweisung macht das Gewünschte:

<b>
update RDB$RELATION_FIELDS set<br>
RDB$NULL_FLAG = 1<br>
where (RDB$FIELD_NAME = 'NameBetreffendeSpalte') and<br>
(RDB$RELATION_NAME = 'NameBetreffendeTabelle')<p>
</b>
<p>
<p>
<font color="#FF0000"><strong><u>Warnung</u></strong></p>

Grundsätzlich sollte vor dem Manipulieren der Systemtabellen zwingend die Datenbank gesichert werden. Darüber hinaus sollte man an den Systemtabellen nur etwas ändern wenn man weiß was man macht.
</font><p>
Tschüß

Torste

[Mathias Berg]

Hi Torsten,

Danke für den Tipp; funktioniert auch. Deine Warnung hat mich veranlasst mir die Doku für IB über die Systemtables genauer anzuschauen.(ftp://ftp2.interbase.com/pub/products/beta6.0/ib_b60_doc.zip; stand 03/2000; gibt es da schon neuere?)

Hierbei ist mir aufgefallen, dass rdb$check_constraints auch Einträge für Columns mit dem attribut not null hält. Ich habe das mal durch einen tablecreate mit einer "not null" Spalte getestet.

Da wird dann tatsächlich ein eintrag in rb$check_constraints angelegt. Da dachte ich mir jetzt ist ein guter zeitpunkt das Tool gfix mit dem Kommando -validate auszuprobieren. Ich bekam keinen Error, aber auch sonst keine Meldung... (ich hasse solche tools!)

Was hälst du davon?

Gruß
Mathia

[Wolfhard Kupfer]

Hallo,

folgendes hat funktioniert:<br>
<code>
create table test (id integer);<br>
create domain testdom as integer not null;<br>
alter table test alter id type testdom;<br>
</code>

Best Regards<br>
Wolfhar

[Torsten Grundke]

Hallo Mathias,

soweit ich weiß gibt es keine aktuellere Doku.

Zum Thema GFIX kann ich Dir leider nicht allzuviel sagen. Bisher noch keine praktischen Erfahrungen (Gott sei dank noch nicht notwendig gewesen - bezogen auf beschädigte Datenbank). Wenn Du keine Fehlermeldung erhalten hast, dann ist alles in Ordnung. Erläuterungen zu den einzeln Optionen von GFIX habe ich nur in Buch von Holger Klemt
INTERBASE 4.x/5 gefunden. Gibt es allerdings nicht mehr im Buchhandel. Andreas Kosch hat ein Buch zum Interbase 6 angekündigt und eventuell werden da auch die einzelnen Optionen erläutert.

Tschüß

Torste