Josef: Mehrbenutzersystem

Jo is gleich halb eins, also einen guten morgen
wie realisiere ich am besten ein abgestuftes Mehrbenutzersystem in php, das den Zugang zu einem bestehenden Kalenderscript erlaubt/verweigert?

Gruß Josef

ps: Ich nähre meinen eigenen moralischen Unhold auch immer aus meiner eigenen Selbstausbeutung und lasse ihn immer um Mitternacht von meinem Blut trinken deswegen bin ich jetzt etwas müüüüüüüüüüüüüüüüüüüde.

  1. Hello Josef,

    Jo is gleich halb eins, also einen guten morgen
    wie realisiere ich am besten ein abgestuftes Mehrbenutzersystem in php, das den Zugang zu einem bestehenden Kalenderscript erlaubt/verweigert?

    Indem Du Dinge beachtest, wie

    • Vorgangsbearbeitung
    • Formular-Zertifikate
    • Intelligente Lockingstrategien

    Dann kann man den Usern "Level" geben, die dann immer mehr dürfen
    Man kann den Objekten Eigentümer geben.
    User bis Level 20 dürfen dann z.B. nur die Objekte sehen, die ihnen selber gehören
         ab  Level 21 dürfen sie dann auch andere Objekte sehen aber noch nicht alle

    Man kann dem Objekt selber auch einen Level als Eigenschaft geben

    Man kann den Objekten auch verschiedene Eigenschaften geben:

    • Read            sehen bei qualifiziertem Aufruf
    • Create          anlegen eines Neuen Objektes dieser Klasse
    • Alter           Ändern des Objektes
    • delete          Löschen des Objektes
    • daisy-chain     Weitergeben an Andere (die selber sonst nicht die obigen Rechte hätten)
    • browse          Auflisten lassen des Objektes bei unqualifizierter Anbfrage (Liste)
    • access-Control  Rechtevergabe an Andere für diese Objekt im Rahmen der eignen Rechte
    • Supervise       Generelle Rechtevergabeauf das Objekt, auch außerhalb der eigenen eingestellten

    Alle diese Rechte kannst Du nun in einem Byte als Flags signieren oder in mehreren auch noch abstufen mit Leveln. Nur wenn die effektiven rechte des Users ausreichen, dieses Objekt zu behandeln, weird es freigegeben.

    Und Du brauchst für Ausnahmen sogenannte Trusties.
    Dafür benötigt man eine eigene Tabelle, in der dann gezielt eine Beziehung des Benutzers mit dem einzelnen Objekt hergestellt wird.

    Man kann Benutzer in Gruppen zusammenfassn und Objekte auch.

    Hat der Benutzer nun auf das Leitobkjekt (Directory) generelle Rechte, so vererben die sich auf alle Objekte-Benutzerpaarungen dieser Gruppe.

    Gehört der Benutzer einer Gruppe an, die auf eine Objektgruppe Rechte hat, so vererben sich auch diese weiter.

    Das führt zu der Erkenntnis, dass man auch eine Vererbungssperre benötigt, für den Fall, dass man einem Benutzer wieder ererbte Rechte entziehen muss für eine untergeordente Hierarchisstufe.

    Und das führt nun wieder dazu, dass man immer den gesamten Objektbaum von der ROOT bis zum Objekt durchlaufen muss, um feststellen zu können, ob iergendwo eine Sperre vorliegt.

    Die Schwierigkeit liegt nun darin, dass man Objekte im Baum verschieben können muss und dabei mdie effektiven Rechte nicht durcheinander bringen darf. Sonst könnte es passieren, dass man ein Objekt mit hohen Rechten für den Benutzer aus einer tiefen Hierarchiestufe nach oben bewegt, und der Benutzer dann plötzlich diese Rechten für den ganzen untergeordneten Baum hat.

    Wie man in der verbindungslosen Client-Server-Internet-Technik das Locking von Vorgaangsschritten regeln kann, weißt Du hoffentlich. Sonst musst Du dich gedulden, bis mein Feature-Artikel dazu  fertig ist.

    Viel Erfolg und lass mal lesen, welches Konstrukt Du nun gewählt hast.

    Harzliche Grüße aus http://www.annerschbarrich.de

    Tom

    --
    Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
    Nur selber lernen macht schlau