Best practice: Benutzerverwaltung mit Datenbankanbindung

[mjustin]

Zitat von sx2008:

Also es gibt User, Groups und Permissions (Rechte).
Die Permissions kann man den Usern aber auch den Gruppen zuteilen.
Es besteht als einen N:M Beziehung zwischen User und Permissions als auch zwischen Groups und Permissions.

Warum nicht einfach Benutzer -> Rolle (eine oder mehrere) -> Rechte? Dann kann man immer noch besondere Benutzer definieren, die mehr Rechte haben (Admin). Ist natürlioch Geschmackssache, ob man neben Gruppen auch Benutzer einzeln verwalten möchte.

Neben dem Anbinden von Rechten an GUI Elemente wünsche ich mir ein Delphi eine Möglichkeit sie über Attribute an Methoden zu binden, so wie es das Apache Shiro Framework kann. Dann könnte man in beliebigen Anwendungsarten (Kommandozeile, Service, Webanwendung) unmittelbar auf Ebene der Geschäftslogik die Rechte prüfen, anstatt in der Visualisierungsschicht.

Delphi-Quellcode:

//Will throw an AuthorizationException if none
//of the caller’s roles imply the Account 
//'create' permission
[RequiresPermissions(“account:create”)‏]
procedure openAccount(acct:  Account);
begin
    //create the account
end;

[Stevie]

Zitat von mjustin:

Neben dem Anbinden von Rechten an GUI Elemente wünsche ich mir ein Delphi eine Möglichkeit sie über Attribute an Methoden zu binden, so wie es das Apache Shiro Framework kann. Dann könnte man in beliebigen Anwendungsarten (Kommandozeile, Service, Webanwendung) unmittelbar auf Ebene der Geschäftslogik die Rechte prüfen, anstatt in der Visualisierungsschicht.

Mit method interception geht das.

Allerdings hat das den Nachteil, dass man nicht in der GUI sieht, ob man die Aktion durchführen kann, sondern es kommt erst beim Versuch eine Meldung, dass es nicht geht.

Bei einem RAD Ansatz würde ich wahrscheinlich eher eine eigene TAction Klasse bauen, der man Entsprechende Eigenschaften verpassen kann.