Zeilenweise Rechte auf Sichten oder Tabellen?

[Chrischaaan]

Hallo,

ich habe folgendes Problem: Ich habe 2 Benutzergruppen. Jetzt mal "Gruppe A" und "Gruppe B" genannt. Gruppe A darf auf alle Objekte mit allen Rechten zugreifen. Das ist nicht das Problem. Benutzer der Gruppe B sind Mitarbeiter. Diese Mitarbeiter dürfen jedoch nur auf Zeilen zugreifen, bei denen Sie als Mitarbeiter eingetragen sind. Voraussetzung dazu ist, dass sie mit dem selben Namen in der Tabelle Mitarbeiter stehen...

Ich habe also eine Tabelle Mitarbeiter wo der Mitarbeiter u.a. mit Vor- und Zuname drin steht. Und einen Login der den selben Vor- und Zunamen enthält. Es muss aber nicht sein, dass ein Mitarbeiter, der in der Mitarbeitertabelle steht auch einen Zugriff hat. In diesem Fall kommt er an die DB ja eh nicht ran. Das spielt dann keine Rolle weiter. Wenn er Zugriff hat, aber nicht in der Mitarbeitertabelle steht bekommt er einfach keine Ergebnisse aus der Sicht. Aber wie Frage ich ab ob der Login mit dem Namen in der MA-Tabelle übereinstimmt und ob der Mitarbeiter für den Kunden als Mitarbeiter eingetragen ist? Letzteres müßte ja relativ leicht über einen Join zu lösen sein...

Wäre für Hilfreiche Ideen dankbar!

bye, Christian.

[fanderlf]

vielleicht könntest mal grob dazuschreiben wie deine Datenbank aussieht? Welche Foreign Keys es konkret gibt und welche Daten Du für eine Abfrage konkret zur Verfügung hast.

Ich kann mir unter obigem Beispiel ehrlich gesagt schlecht vorstellen wie das ganze aussieht.

[Chrischaaan]

hallo,

ich hab die tabelle mitarbeiter und die mit den kunden.
beide sind über einen foreign key auf die spalte MA_ID miteinander verbunden.
ma_id ist bei der tabelle mitarbeiter der primary key.
bei der tabelle "kunden" ist kundenid der PK.

ziel wäre jetzt: der mitarbeiter max mustermann loggt sich ein und sieht alle kunden aus der kundentabelle bei denen er als mitarbeiter drin steht. sozusagen alle kunden, bei denen in der spalte ma_id seine mitarbeiter_id eingetragen ist.


folgende abfrage kann ich ausführen, das führt zum gewünschten ziel.

SELECT *
FROM Kundendaten k, Mitarbeiter m
WHERE k.MA_ID = m.MA_ID
AND Vorname = 'Max' AND Nachname = 'Mustermann'

den vor- und nachnamen würde ich aus den logindaten im programm übernehmen (war jetz meine idee. weiß nich, ob das so praktikabel ist. aber irgendwoher muss ich ja mit der anmeldung vergleichen...)


jetzt könnte ich daraus ne sicht machen. aber nun ist das problem, dass ich ja dann für jeden mitarbeiter ne sicht machen müßte. das ist auf dauer nervig. selbst, wenn die mitarbeiter nicht oft wechseln.
zudem müßte, wenn diese sicht die einzige sicht sein soll aus der ich abfrage, die "gruppe a"; die ja alle daten sehen darf; ja noch irgendwie zugreifen können. faktisch müßte bei den "gruppe a"-leuten die WHERE-klausel entfallen.

wie macht man das am sinnvollsten?


ich hoffe, die beschreibung hilft etwas weiter.

edit:
dann ist da noch ein problem: bei manchen tabellen hat der mitarbeiter das recht, daten hinzufügen oder ändern zu dürfen. das hab ich an sich schon durch die rollenrechte realisiert. ist das ausreichend, wenn der dann eh nur die daten ändern könnte die der sieht? er sieht ja nicht alle daten. also kann er auch nicht alle ändern. oder gibts da ne lücke zwischendrin? sollte der besser nur in der sicht ändern dürfen?

[fanderlf]

Warum setzt du denn das query nicht einfach vom programm aus ab? Ein View ist am Ende auch nichts anderes als ein SQL Query was jedesmal ausgeführt wird, wenn jemand auf den View zugreift.
Wenn Du die Logik unbedingt in der Datenbank haben willst könnte man noch eine Stored Procedure anlegen die Dir dann eine entsprechende Tabelle zurückgibt.
Mit einem View wird das wohl nicht gehen.

Hat in Deinem Programm jeder Benutzer einen eigenen Datenbank Zugang? Eventuell könnte man dann diesen Loginnamen abfragen und den in die Abfrage für das View einbauen. Allerdings weiss ich nicht ob sich so etwas realisieren lässt. Da kommts wohl auch auf die verwendete DB an.

[Chrischaaan]

hi,

ja, es hat jeder benutzer einen eigenen login.
ich hab auch schon daran gedacht, jedes mal mit nach dem namen zu fragen. aber das würde halt x-sichten erfordern...

den query vom programm aus setzen ist an sich nich das ding. problem ist halt folgendes:

wenn sich jmd. aus der gruppe a einloggt darf dieser jemand zwar eigentlich alle daten sehen, steht aber nicht in der mitarbeiter-tabelle und bekommt aufgrund des joins keine ergebnisse.

ist es so praktikabel erst zu vergleichen ob der eingeloggte user in der MA-tabelle steht und danach dann den abfragestring wählen oder gibts ne sinnvollere lösung?

[dbwizard]

hi,

ja, es hat jeder benutzer einen eigenen login.
ich hab auch schon daran gedacht, jedes mal mit nach dem namen zu fragen. aber das würde halt x-sichten erfordern...

den query vom programm aus setzen ist an sich nich das ding. problem ist halt folgendes:

wenn sich jmd. aus der gruppe a einloggt darf dieser jemand zwar eigentlich alle daten sehen, steht aber nicht in der mitarbeiter-tabelle und bekommt aufgrund des joins keine ergebnisse.

ist es so praktikabel erst zu vergleichen ob der eingeloggte user in der MA-tabelle steht und danach dann den abfragestring wählen oder gibts ne sinnvollere lösung?

Hallo,

ich kapiere dein Problem nicht ganz ? Wenn dein MA sich einloggt, besitzt er ja eine eindeutige Identifizierung (Nachname und Vorname sind für sowas allerdings denkbar ungeeignet), also z.b. eine UNIQUE User_ID. Füge die doch einfach an dein SQL, welches die Abfrage erledigt an und gut ist ? Oder habe ich dich falsch verstanden ?


@fanderlf: Ein SQL im Client ist (meine Ansicht) der sicher "falscheste" Ansatz für so etwas...

Gruss

[fanderlf]

Ehm... jeder der eine SQL Abfrage ausführt ist ein Client. Selbst wenn ich mit SQL*Plus auf die Datenbank gehe bin ich am Ende Client.

Wie soll er das SQL deiner Meinung nach gestalten, wenn es nicht Clientseitig sein darf? Er soll was an sein SQL anfügen darf dies aber nicht am Client machen. Wo soll er denn dann sein Benutzerinformationen übergeben?

Wenn man clientseitiges SQL vermeiden will gäbe es noch 2 Möglichkeiten:
1. Stored Procedure
2. Eine View mit einer Abfrage des User aus der Session (wobei ich mir hier nicht sicher bin, ob sich so etwas realisieren lässt)

Ob das Design jetzt toll ist oder nicht, darüber lässt sich streiten. Aber oft kann man das Design auch nicht einfach ändern.

[dbwizard]

Ehm... jeder der eine SQL Abfrage ausführt ist ein Client. Selbst wenn ich mit SQL*Plus auf die Datenbank gehe bin ich am Ende Client.

Wie soll er das SQL deiner Meinung nach gestalten, wenn es nicht Clientseitig sein darf? Er soll was an sein SQL anfügen darf dies aber nicht am Client machen. Wo soll er denn dann sein Benutzerinformationen übergeben?

Wenn man clientseitiges SQL vermeiden will gäbe es noch 2 Möglichkeiten:
1. Stored Procedure
2. Eine View mit einer Abfrage des User aus der Session (wobei ich mir hier nicht sicher bin, ob sich so etwas realisieren lässt)

Ob das Design jetzt toll ist oder nicht, darüber lässt sich streiten. Aber oft kann man das Design auch nicht einfach ändern.

Wie soll er das SQL deiner Meinung nach gestalten, wenn es nicht Clientseitig sein darf? Er soll was an sein SQL anfügen darf dies aber nicht am Client machen. Wo soll er denn dann sein Benutzerinformationen übergeben?

- Nun, in der DB ? Wenn er sich an der DB anmeldet mit seinen Logindaten, ist der Benutzer ja bekannt ?

1. Stored Procedure
2. Eine View mit einer Abfrage des User aus der Session (wobei ich mir hier nicht sicher bin, ob sich so etwas realisieren lässt)

- Genau so :-). Ich würde es sicher mal in ein Package packen und dort etwa so realisieren : (Oracle, ohne Exception etc....)

PROCEDURE get_something (
      i_nuser_id  IN       NUMBER,
      rc            OUT      sys.ref_cursor
   )
   IS
   BEGIN
      OPEN rc FOR
         SELECT wasauchimmer from mytable WHERE user_id=i_nuser_id;
   END;

Gruss

[fanderlf]

Naja hatte ich ja auch ein paar Antworten vorher auch geschrieben. Aber ich denke man muss auch nicht jede SQL Abfrage in eine Stored Procedure packen.
Gerade wenn man in der Client Anwendung einen Data Layer hat den alle zukünftigen Programme nutzen sollen, dann kann man das SQL meiner Meinung nach auch dort hinein packen.

Die Frage des Threaderstellers war allerdings ob er denn nun abhängig von dem Login ein View erstellen könnte was jedem Benutzer die entsprechenden Zeilen anzeigt.

Etwa sowas:

with username as
(
  SELECT sys_context( 'userenv', 'session_user' ) UserName FROM dual
)
SELECT Kunden.*, Mitarbeiter.*
FROM Kunden, Mitarbeiter, username
WHERE Kunden.MA_ID = Mitarbeiter.MA_ID
AND username.UserName = Mitarbeiter.UserName

Das with müsste nicht unbedingt sein, aber man sieht etwas deutlicher was ich meine.

Edit: Hab gerade versucht so eine View zu erstellen und das hat geklappt Jetzt musst Du dir halt den Datenbank Benutzer so auseinander nehmen, damit Du den auf Deine Tabelle anwenden kannst.

[dbwizard]

Naja hatte ich ja auch ein paar Antworten vorher auch geschrieben. Aber ich denke man muss auch nicht jede SQL Abfrage in eine Stored Procedure packen.
Gerade wenn man in der Client Anwendung einen Data Layer hat den alle zukünftigen Programme nutzen sollen, dann kann man das SQL meiner Meinung nach auch dort hinein packen.

Die Frage des Threaderstellers war allerdings ob er denn nun abhängig von dem Login ein View erstellen könnte was jedem Benutzer die entsprechenden Zeilen anzeigt.

Etwa sowas:

with username as
(
  SELECT sys_context( 'userenv', 'session_user' ) UserName FROM dual
)
SELECT Kunden.*, Mitarbeiter.*
FROM Kunden, Mitarbeiter, username
WHERE Kunden.MA_ID = Mitarbeiter.MA_ID
AND username.UserName = Mitarbeiter.UserName

Das with müsste nicht unbedingt sein, aber man sieht etwas deutlicher was ich meine.

Edit: Hab gerade versucht so eine View zu erstellen und das hat geklappt Jetzt musst Du dir halt den Datenbank Benutzer so auseinander nehmen, damit Du den auf Deine Tabelle anwenden kannst.

Gerade wenn man in der Client Anwendung einen Data Layer hat den alle zukünftigen Programme nutzen sollen, dann kann man das SQL meiner Meinung nach auch dort hinein packen.

- Das könnte man natürlich zu "Ende denken" und sagen:Wenn alle zukünftigen Clients diese Funktion nützen sollen, dann gehört es in die DB (oder auf den Applikationsserver....). Ich bin kein grosser "Fan" von SQL auf Client's, auch wenn es sicher mal eine Situation gibt, in der sich so etwas rechtfertigt

Aber ich denke man muss auch nicht jede SQL Abfrage in eine Stored Procedure packen.

- ich denke, dass man "jedes" SQL (und PL/SQL) in ein Package kapseln soll. Benutzer haben dann ausschliesslich Execute - Berechtigung auf die Packages, welche notwendig sind und nicht "irgendwelche Lese/Schreib Rechte auf weitere DB-Objekte.



Gruss

[fanderlf]

Na gut Es kommt halt drauf an wie sicher das alles sein muss. Wir haben hier eher kleinere Projekte für die sich dieser Aufwand wohl nicht lohnen würde. Jeder der auf die Datenbank zugreifen will soll meine Library benutzen.
Ausserdem fressen mich meine Kollegen, wenn sie das Programm mal warten müssen, weil die in PL/SQL nicht wirklich fit sind

[Chrischaaan]

hallo leute,

dieses script was du mir gegeben hast:

with username as
(
  SELECT sys_context( 'userenv', 'session_user' ) UserName FROM dual
)
SELECT Kunden.*, Mitarbeiter.*
FROM Kunden, Mitarbeiter, username
WHERE Kunden.MA_ID = Mitarbeiter.MA_ID
AND username.UserName = Mitarbeiter.UserName

sieht schonmal sehr vielversprechend aus.
allerdings läuft das ganze (bis jetzt) auf nem sql server 2000.

habt ihr das auch nochmal in ner anderen sql server - variante?


dann ist hier zwischendrin die frage aufgetaucht warum ich das nict direkt über den login-name abfragen will:

die sache ist folgende:
ich habe die kundentabelle und die mitarbeitertabelle. über die erstellte oberfläche ist es möglich dem kunden einen anderen mitarbeiter zuzuordnen. für den fall dass der mitarbeiter kündigt braucht der kunde ja nen anderen der ihn betreut...
deswegen wird der mitarbeiter mit seiner id dem kunden zugeordnet. und nicht ein bestimmter login zu nem kunden...


vielen dank schonmal für die antworten!

bye, Christian.

edit: ich habe die tabelle inzwischen gefunden. sie heißt sysusers...

[fanderlf]

Ich kann mir nicht vorstellen wie das aussieht... auf der einen Seite gibts ne Oberfläche, auf der anderen Seite darf ich nur so programmieren als ich wäre ich direkt in der Datenbank.

Ich meine Du brauchst irgendwoher die Information für die Abfrage. Entweder Du kannst den Benutzernamen des eingeloggten Benutzers verwenden und findest darüber die benötigten Informationen heraus oder nicht.
Andernfalls musst Du diese manuell in die Datenbank bringen. Entweder als Parameter einer Stored Procedure oder eines SQL Kommandos (in Oracle mit @ oder @@ realisiert - andere Datenbanken weiss ich leider nicht).

[Chrischaaan]

hi,

ich habe schon eine oberfläche, ja. dort gibt der nutzer seinen namen und sein kennwort ein. das wird an die DB gegeben und wenn er dort bekannt ist wird er im programm eingeloggt. das heißt, er bekommt eine verbindung zur datenbank.

die daten sind dann folglich auf beiden seiten bekannt. im programm und in der db. jetzt kommen aber die tabellen aus der db und die anmeldedaten liegen bei beidem vor...

mfg, Christian.

[fanderlf]

na wenn du eine Tabelle in der Datenbank wo Du anhand des DB Benutzernamens den jeweiligen Eintrag findest, dann gehts doch so wie ich oben geschrieben habe.
Wenn das nicht so ist, dann musst Du eine Stored Procedure bauen der Du vom Programm aus die benötigten Informationen erhält und Dir die gewünschten Daten zurückgibt.