Firebird+Roles+Rechte

[Ati]

Hallo zusammen,

zu o.g. Thema habe ich mir schon einiges durchgelesen, jedoch komme ich nicht wirklich weiter.
Folgendes Problem habe ich ... ich möchte Zugriffe über definierte Rollen steuern. Also habe ich mal mehrere Benutzer angelegt (ohne Rechte speziell zuzuweisen) und entsprechende Roles. Wenn ich nun bei der Anmeldung den User, Passwort und die Role angebe, so kann der User auch nur die definierten Sachen machen. Jetzt finde ich es aber nicht so gut, das der User seine Role immer angeben muß (diese kann ja bei anderen Anwendungen ganz anders aussehen). Melde ich also nur den User mit Passwort an, in der Hoffnung das die Role dadurch automatisch eingebunden wird, so darf der User gar nichts. Wie schaffe ich es also das ich nur User und Passwort eingebe und die Rechte automatisch über die zugeteilte Role definiert sind?

Ati

[hoika]

Hallo,

Die Rollen des Users auslesen und wenn es nur eine ist,
die benutzen.
Ich hätte gedacht, dass geht über die Systemtabellen.
Etwa so

Select
rdb$user_privileges.rdb$relation_name as RoleName
From
rdb$user_privileges
where
(rdb$user_privileges.rdb$user='MYUSER') and
(rdb$user_privileges.rdb$object_type=13)


Der Nutzernamen muss in Grossbuchstaben sein.

Ich bekome die Rolle aber nicht heraus.
Musst du mal kucken.

Ohne das =13 sehen ich alle Privilegien, ausser meine gerade angelegte Rolle*wunder*

Ein gutes Testwerkzeug ist IBExpert (Personal)
Dort gibt es die Option, die Systemtabellen sich anzeigen zu lassen.


Heiko


Heiko

[Ati]

Sowas in der Art habe ich ja schon versucht...hat aber nicht geklappt.

[Ati]

Ich habe jetzt mal folgendes gemacht. Ich stelle die Verbindung unter "SYSDBA" her. Und suche dann einen vorhandenen User um mir seine Role anzeigen zu lassen (in einem Label-Feld). Hier mal der Code:

Delphi-Quellcode:

procedure TForm1.Button3Click(Sender: TObject);
begin
  qrmain.SQL.Text:='SELECT RDB$RELATION_NAME from RDB$USER_PRIVILEGES where RDB$USER=KLU' ;
  qrmain.ExecSQL;
  label2.Caption:=qrmain.FieldByName('RDB$RELATION_NAME').AsString;
end;

Ich erhalte einen EDatabaseError. Wenn ich die EXE starte sagt das Mistding mir das "KLU" nicht bekannt wäre??

[hoika]

Hallo,

du musst natürlich Open statt ExecSQL nehmen.
Ausserdem fehlt das objecttype=13 (das müßten die Rollen sein).
In der Tabelle stehen alle Felder, auf die ein User Zugriff hat.
Sind ne ganze Menge.

Heiko

[hoika]

Hallo,

lade dir mal bexpert runter,
das hat auch nen Table-Editor (mit Anzeige der Daten)und nen Query-Editor.

Heiko

[Ati]

IBExpert benutze ich schon. Hatte einfach ein Brett vor dem Kopf. Aber Du hast mir den richtigen Denkanstoss gegeben...hier mal der richtige Code:

Delphi-Quellcode:

procedure TForm1.Button3Click(Sender: TObject);
var uname:String;
begin
  uname:='KLU';
  qrmain.SQL.Text:='SELECT RDB$RELATION_NAME from RDB$USER_PRIVILEGES where (rdb$user_privileges.RDB$USER = '''+uname+''') and (rdb$user_privileges.rdb$object_type=13)' ;
  qrmain.open;
  label2.Caption:=qrmain.FieldByName('RDB$RELATION_NAME').AsString;
end;

Werde es morgen wohl so weiterversuchen. Die erste Verbindung wird wohl als Sysdba erfolgen um User, Passwort und Role zu ermitteln. Nach Überprüfung wird die Verbindung dann mit den entsprechenden Userdaten erneut erfolgen....so müßte es doch eigentlich klappen oder?

[hoika]

Jepp,

ich würde das allerdings in eine selectable stored procedure packen,
falls du mal auf ne andere DB umsteigst, sind die rdb$-Tabellenzugriffe hinderlich

Heiko

[Ati]

Hört sich gut an ...... jetzt mal im Ernst ich habe nicht ein Wort verstanden. Kannst Du das mal bitte erklären und vielleicht mit ein bischen Quelltext untermalen?? Danke.

[hoika]

Hallo,

werde ich heute abend mal bauen.
Kurze Info.

Eine selectable stored procedure kann man wie eine
Query aufrufen, z.B.

select * from GetRoles('KLU')

GetRoles ist der Name der stored pro (SP)c.
KLU ist der Username.

Vorteil:
Du kannst die SP auch unter Oracle oder MS-SQL erzeugen
und hast dann eine Unabhängigkeit von der Datenbank.

Nachteil:
Die Syntax zum Erzeugen der SP ist nicht richtig so standardisiert.
Jeder Hersteller kocht da so sein Süppchen.
Der SQL-Standard (99) definiert zwar, wie eine SP aussehen soll,
aber kein Hersteller hält sich 100% ig dran,
ausserdem haben die noch "Spracherweiterungen".


Heiko