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