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

[Ati]

Also ist jetzt wohl der Zeitpunkt gekommen, wo ich mich mit "Stored Procedures" beschäftigen muß wie? Hatte mich bisher immer davor gedrückt, da es mir schwierig und kompliziert erschien. Aber naja kann ja eigentlich nur förderlich sein. Wobei ich bei meinen bisherigen Berührungspunkte nie unterscheiden konnte, wo eine SP Sinn macht und wo nicht.

[hoika]

Hallo,

die kurze Antwort zur Benutzung wäre,
überall, wo es möglich ist ;)

http://www.ibphoenix.com/main.nfs?a=..._intro_sp_trig


Probleme gibt es aber auch:
- Aktualisierung (z.B. neuer Parameter) ist nicht ganz so leicht wie in Delphi.
- Sprach- / Funktionsunterschiede der einzelnen Datenbank-Server.


Gerade der 1. Punkt ist hart.


Heiko

[Ati]

Nun ich bin noch ziemlich am Anfang der DB-Programmierung deswegen sagt mir Punkt 1 nicht viel. Jedoch habe ich die letzten Stunden viel mit experimentieren und lesen bezgl. SP´s verbracht...gerade dadurch will mir noch nicht so richtig klar werden wie die Abfrage der "Role" und das entsprechende zuweisen der Berechtigungen mit einer SP geht. Bin also ganz begierig auf Deinen Beispielcode, für den ich mich jetzt schonmal bedanken möcht.

[hoika]

So,

das ganze unter IBExpert.
- DB registrieren
- dann bei Procedures Rechts-Klick New(Neu)
- auf der rechten Seite in der Toolbar "LazyMode aus"
(das ist links vom Compile, also dem Blitz)
- alles aus dem Editor rauslöschen
- jetzt gaaanz nach oben , ALLES raus ;)
(der Cursor steht nicht in der 1. Zeile)
- Folgendes von Hand eintippen

Schlaue Leute Copy&Paste *fg*

SQL-Code:

Create Procedure SP_GETROLESONUSER (
    THEUSERNAME VarChar(31))
Returns (
    THEROLES VarChar(31))
As
Begin
  For Select
    rdb$user_privileges.rdb$relation_name as RoleName
  From
    rdb$user_privileges
  Where
   (rdb$user_privileges.rdb$user=:TheUserName) and
   (rdb$user_privileges.rdb$object_type=13) into :TheRoles do
  Begin
    Suspend;
  End
End

- Compile (der Blitz)
- die Meldung bestätigen
- F12 (Query-Editor)
select * from SP_GETROLESONUSER('KLU');
- F9

Ergebnis sind die Roles (auch mehrere).

Diese "selectable stored procedure" wird also wie eine Query benutzt,
die allerdings einen Parameter hat.


Kurze Erklärung:
- THEUSERNAME ist der Input-Parameter
es wird Groß-Buchstaben verlangt
sonst muesste man in der SP ein

SQL-Code:

  (rdb$user_privileges.rdb$user=:TheUserName)

schreiben.

- THEROLES ist Ausgabeparameter

- Das "For Select Into" erzeugt einen Cursor

- das Suspend wartet solange, bis der Client den Datensatz abholt (fetch)



UND WOZU DAS ALLES ?

1.
Der Code kann von verschiedenen Programmen benutzt werden.

2.
Die gleiche SP, allerdings mit einem anderen Code intern,
kann man für mehrere Datenbanken (Oracle) schreiben



Heiko
PS:
Die SP hat nichts mit der Role-Zuweisung zu tun,
dafür gibt es GRANT.

[Ati]

Vorab erstmal vielen Dank für Deine Mühe und Hilfe. Nun mal zurück zum Programm. Ich werde den Programmablauf mal mit meinen Worten fassen okay?
Ich erstelle ein Anmeldeformular in welchem Username und das Passwort angegeben weden muß. Nach der Eingabe rufe ich die SP auf (hier müßte doch eigentlich auch noch das Passwort auf Richtigkeit geprüft werden oder??), welche die zugewiesene Role ermittelt. Aber wie geht es dann am besten weiter?? Soll die SP die Role zurückgeben und das Programm meldet sich nochmal mit allen drei Variablen (User,Pass,Role) an oder soll per GRANT dem User die Rechte der Role zugewiesen werden. Und wenn ja was macht man wenn ein User mehrer Roles hat? Werde aber morgen früh Deine Anleitung erstmal ausprobieren.

Ati

[hoika]

Hallo,

1. UserName, Passwort abfragen (editor)

2. anmelden als SYSDBA und alle Rollen des Users abfragen
hat der User keine Rollen
tja 2.a Abbruch
2.b ohne Rolle anmelden

3. wenn es nur eine Rolle ist (die Rollen packt man z.B. in eine StringList)
anmelden unter dieser Rolle

wenn er mehrere hat, ComboBox einblenden, wo die Rollen
angeeigt / vom User eingestellt werden

4. Die Richtigkeit des Passwortes bekommst du nur mit,
wenn das Connect erfolgreicht war.

eine andere Möglichkeit gibt es afaik nicht


Heiko

[Ati]

Irgendeine Kleinigkeit mache ich wohl noch falsch. Also wenn ich die SP in IBExpert ausführe funktioniert alles. Versuche ich die SP durch mein Delphi/Lazarus-Programm aufzurufen kommt eine Fehlermeldung (s.Anhang). Aber es gibt ja eindeutig diesen User. HAbe zu Testzwecken auch mal einen weiteren angelegt aber auch mit dem klappt es nicht. Hier mal mein Code:

Delphi-Quellcode:

procedure TForm2.Button1Click(Sender: TObject);
var user,rolle,pass:String;
begin
  user:=upcase(eduser.Text);
  pass:=edpass.Text;
  qrlog.sql.text:='select * from SP_GETROLESONUSER('''+user+''')';
  qrlog.open;
  label3.Caption:=qrlog.FieldByName('THEROLES').AsString;
end;

Ati

[Ati]

Ich verstehe es einfach nicht... wenn ich die Abfrage der Role aus dem Program heraus mache funktioniert alles (hier mal der entsprechende Code):

Delphi-Quellcode:

user:=upcase(eduser.Text);
  qrlog.SQL.Text:='SELECT RDB$RELATION_NAME from RDB$USER_PRIVILEGES where (rdb$user_privileges.RDB$USER = '''+user+''') and (rdb$user_privileges.rdb$object_type=13)' ;
  qrlog.open;
  label3.Caption:=qrlog.FieldByName('RDB$RELATION_NAME').AsString;

Aber hier wird doch nichts anderes gemacht als in der SP. Zumal in der Fehlermeldung ja der USER 'KLU' auch angezeigt wird, demnach kann es doch kein Fehler in der Parameterübergabe geben oder?

[hoika]

Hallo,

- Anmeldung als SYSDBA, und hole der Rollen des Users
- hat er mehr als eine -> Abfrage (Combobox ?)
- Anmeldung des Users+Pass+Role

Die Prüfung ob das Passwort gültig ist erfolgt beim Login.
Eine Abfrage wie "Ist Passwort gültig?" gibt es nicht.


Heiko