Transaktionsabhängige Variable / Userverwaltung Firebird

[Artur]

Guten Morgen!

Gibt es eine Möglichkeit Variablen transaktionsabhängig zu setzen, d.h. eine Variable, die aber je nach Transaktion einen anderen Wert beinhaltet?

Hintergrund: ich mache derzeit meine User-Verwaltung nicht über die DB User, sondern in einer Tabelle.
Mein Programm meldet sich immer mit dem gleichen User an. Wenn jemand etwas ändert setze ich derzeit den ändernden User manuell im Programmcode, schöner wäre es natürlich das über einen Trigger automatisch realisieren zu lassen.


Wie macht Ihr das überhaupt mit mehreren Usern, verwendet Ihr die Userverwaltung des DB Systems?
Vielleicht noch als Zusatzinfo: ich verwende auf den Laptops nur die FB embedded.
Und wie macht Ihr es dann mit dem Anmelden des Users an der DB bei der Installation? Eigenes Proggie?


Ciao,

Artur

[Jelly]

Du wirst das nicht triggern können, wozu auch?

Entweder du verpasst deinen Benutzer gleich einen Usernam mit Passwort direkt unter Firebird, oder du nutzt nur einen Firebird User, und nach dem Login, verwaltest du deine Benutzer in deinem Code.

[kretabiker]

Guten Morgen Artur,

ich denke, der angemeldete DB-User läßt sich nicht durch Programmcode ändern - zumindest nicht auf offiziellen Weg, vielleicht gibt es einen Hack dafür. Wäre m.E. aber übel, denn am angemeldeten User hängt datenbankseitg ne Menge - vor allem Rechte (auf Tabellen, Views, SPs usw). Wenn man sich mit einem minderpriviligierten User anmeldet und dann durch einfaches umcodieren des Users mehr Rechte verschaffen könnte - ohaoha...

Zitat:

Wie macht Ihr das überhaupt mit mehreren Usern, verwendet Ihr die Userverwaltung des DB Systems?

Wir setzen in unseren Applikationen sehr auf die Userverwaltung von Firebird, da wir mit dedizierten Rechten für einzelne Usergruppen arbeiten. Dabei kommen dann unterschiedlichen Rollen (Roles) zum Einsatz, die im RDBMS definiert sind. So darf ein Standard-User zwar Vorgänge erfassen, hat aber nichts in der Umsatzauswertung zu suchen und schon gar nichts in der Provisionsauswertung - das dürfen nur "priviligierte" User, und das wird alles geregelt über Roles, Views usw. (Allerdings gibt es in den Applikationen auch noch entsprechende Massnahmen, um die Anwender vor den recht unfreundlichen Meldungen des Servers wegen fehlender Rechte zu schützen)

Trotzdem führen wir eine Usertabelle in den Datenbanken mit, da darüber solche Dinge wie Ablauf des Kennwortes, fehlerhafte Anmeldeversuche usw. geregelt werden. Unsere Userverwaltung ist also zweistufiger Natur.

Nachteile des Verfahrens:
Zum einen wird für das Bearbeiten der Firebird-Userverwaltung der User sysdba vorausgesetzt, so dass wir gezwungen sind, entweder immer das gleiche sysdba-Passwort zu verwenden oder für jeden Kunden mitzuprotokollieren, welches sysdba-Kennwort eingestellt wurde (hier kann es aber auch sein, dass wir trotz intensiver Suche nach einer anderen Lösung etwas übersehen haben).

Ein weiterer Nachteil ist, dass das Ausgestalten der Rollenrechte manchmal etwas difizil ist; da brauchte es gerade am Anfang ein wenig Zeit, bis alles paßte.

Dritter Nachteil: Der Anmeldeprozess gestaltet sich aufwendiger, da eben in zwei Stufen: erst bei Firebird anmelden, dann in der DB-Usertabelle nachschlagen, ob vom User andere Aktionen erforderlich sind, z.B. turnusmäßiges Kennwort-ändern oder ähnliches.

Dagegen stehen aber m.E. viel mehr Vorteile, die die Nachteile mehr als aufwiegen. Dadurch, dass für jeden Anwender ein eigener Anmeldename verwendet wird, wird dieser auch an die DB durchgereicht und kann dann dort genutzt werden. So kannst du z.B. bei Änderungen den Usernamen über Trigger in die Tabelle schreiben lassen - genau das, was du willst (wenn ich es richtig verstanden habe).

Zitat:

Und wie macht Ihr es dann mit dem Anmelden des Users an der DB bei der Installation? Eigenes Proggie?

Zum einen haben wir eine Userverwaltung im Hauptprogramm, wo dann User der Admin-Gruppe neue User anlegen können (da kommt dann leider das sysdba-Problem zum Tragen). Zum anderen haben wir ein Admin-Programm, das bei der Installation verwendet wird, um den ersten User anzulegen - das ist ein von uns vordefinierter Admin-User, den wir auch für Supportfälle verwenden. Während der Schulung wird dann beigebracht, wie Kunden selbst User anlegen und bearbeiten können.

Ach ja, die Ausführungen beziehen sich auf FB 2.x SS, nicht embedded - zu letzterem kann ich nichts sagen.

Das alles trifft jetzt nicht den Kern deiner Frage - wie sich an der Datenbank angemeldete User transaktionsabhängig verändern lassen -, aber vielleicht bestärkt es dich, auf dedizierte Anmeldeuser umzustellen. Der Mehraufwand in der Entwicklung ist einmal am Anfang zu leisten, danach überwiegen die Vorteile.

Gruß aus Hamburg

Kretabiker

[Artur]

Hallo

@Kretabiker: WOW, vielen, vielen Dank für die sehr ausführliche Antwort
Ich muss mir dass mal durch den Kopf gehen lassen, ob ich es ähnlich mache. (Vom Prinzip könnte ich auch hergehen, und beim Anmeldeversuch prüfen, ob der User in meiner Tabelle drin ist, ihn dann anlegen, die Transaktion wechseln und mit dem User weitermachen. Muss da mal bei Gelegenheit etwas Gehirnschmalz investieren. Da ich das Proggie nur für uns schreibe, habe ich wenigstens kein Problem mir alle SYSDBA merken zu müssen, kann global einen definieren :-) ).

@Jelly: Ich habe die Frage blöd formuliert:
Ich möchte zu Beginn der Transaktion eine Variable setzen und diese über einen Trigger in die DB eintragen.
Das Problem ist, dass ich pro Transaktion einen anderen Wert in dieser Variable bräuchte (obwohl die Transaktionen vom "gleichen User" gestartet werden).


Ciao,

Artur

[Jelly]

Zitat:

Zitat von Artur

@Jelly: Ich habe die Frage blöd formuliert:
Ich möchte zu Beginn der Transaktion eine Variable setzen und diese über einen Trigger in die DB eintragen.
Das Problem ist, dass ich pro Transaktion einen anderen Wert in dieser Variable bräuchte (obwohl die Transaktionen vom "gleichen User" gestartet werden).

Also sorry, aber ich habs immer nicht gerafft :wall:
Von welcher Variable redest du. Wenn du ein Varible in Delphi änderst, wie bitte soll dadurch in der Datenbank irgendwas getriggert werden.

Was heisst pro Transaction? Ich doch mal davon aus dass du pro Connection nur eine Transaction hast.

Vielleicht könntest du dir eine Parametertabelle anlegen, die pro User unterschiedliche Parameter hinterlegen kann. Aber ich muss da erstmal besser verstehen, was dein Problem ist.

[alex517]

Hallo Artur,

das was du suchts findest du z.B. in den Release Notes unter "Context Variables".
Mit rdb$set_context() kannst du eine Variable für einen bestimmten Context
(z.B. USER_SESSION, USER_TRANSACTION, SYSTEM) setzen
und z.B. in einem Trigger mit rdb$get_context() wieder abrufen.

Ich würde die Variable die den Benutzer identifizieren soll beim Login,
im Context USER_SESSION setzen. Damit gilt er in allen Transationen dieser Session (Connection).


alex

[Artur]

Ich habe pro Connection 2 Transactions (read / write), da ich mit FIBplus arbeite.

Ich meine keine Delphi Variablen (das wäre ja simpel). Ich rede davon Variablen im FB zu deklarieren. Innerhalb der SPs geht sowas ja. Die Frage ist, ob ich das auch pro Connection kann und wenn ja wie?

Derzeit verwende ich einen Trigger um Änderungen mitzuschreiben:

SQL-Code:

AS
DECLARE VARIABLE  actuser VARCHAR(18);
begin
  /* Trigger text */
  actuser = USER;
  if (actuser <> 'REPLICATOR') then
  begin
    if (inserting) then
    begin
      NEW.db_inserted_at = 'NOW';
      NEW.db_inserted_by = USER;
      NEW.db_need_rep = '1';
    end
    NEW.db_changed_at = 'NOW';
    NEW.db_changed_by = USER;
    if (NEW.db_need_rep <> '1') then NEW.db_need_rep = '2';
  end
  else NEW.db_need_rep = '0';
end

Bei User steht bei mir natürlich immer das Gleiche drin, weil mein Proggie immer den gleichen User verwendet (außer bei der Replikation, daher der zweite User REPLICATION).

Wenn man jetzt im FB eine Variable setzen können, wie z.B. einen Generator und könnte man einen Wert hier eintragen ('Hr Eintipper'), wäre ich einen Schritt weiter. Aber es würde nur was bringen, wenn es sich pro Connection differenzieren ließe, da unter Umständen mehrere Proggies gleichzeitig auf den Server zugreifen (statt auf die lokale DB ).

[Artur]

Hi alex517

super, dass sieht so aus, als wär es die Lösung, die ich suche.
Vielen Dank.

Ciao,

Artur

[Jelly]

Ah jetzt ja :lol:

Da denke ich, Alex hat in #6 die Antwort dazu gegeben.

[mkinzler]

Wie alex517 beschrieben hat, bietet FB ab Version2 die Möglichkeite benutzerdefinierte kontextvariablen anzulegen. Diese können global, transaktionsabhängig oder Uuserbezogen sien.