Benutzerrechte bei Webseiten

[Jesus_666]

Ich gebe dem vorgeschlagenen Verfahren mal seinen Namen: Access Control Lists (ACLs). ACLs finden sich in allen ernstzunehmenden Betriebssystemen und sind gar nicht mal so schwer.

Mog hat das ganz gut beschrieben; ich füge dem noch mal als Gedankenexperiment hinzu, daß man ein System aufbauen könnte, in dem alles und jeder eine ACL haben kann.
Dazu wird so ziemlich alles, was es im System gibt (User, Usergruppen, Blogeinträge, sogar ACLs) in einer zentralen Objekttabelle verzeichnet (hauptsächlich, damit alle Objekte eine ID im selbenden fortlaufenden Nummernbereich haben). Die ACLs weisen dann einfach beliebigen Objekten auf beliebigen anderen Objekten Rechte zu.

Ach ja; die Objekte sollten hierarchisch organisiert sein, damit Rechtevererbung möglich ist. So kann man Standardregeln festlegen, indem man einfach die ACLs das Wurzelelement referenzieren läßt.

Die zentrale tabelle folgt in Pseudocode. "#" bezeichnet Kommentare.
Man verzeihe mir, daß ich vermutlich die Indizes falsch gesetzt habe und Fremdschlüssel gar nicht verwende; Datenbanken habe ich nie formell gelernt, weil der Kurs zeitlich blöde aufwändig ist.

Zuerst mal hat man eine Tabelle, die die ACL-Einträge beinhaltet:

Code:

TABLE ACLEntries
  int        acl_id        # ID der ACL
  int        object_id     # ID des Objekts, auf das zugegriffen werden soll
  int        subject_id    # ID des Objekts, für das die Berechtigung gilt
  varchar    action        # Aktion, die erlaubt/verboten wird
  tinyint(1) isProhibition # Ist der Eintrag ein Verbot?
  INDEX acl_id

  # Man hätte für action auch eine ID nehmen können; dann würden alle möglichen
  # Aktionen in einer weiteren tabelle stehen und könnten auch ACLs haben.

Der Eintrag 300, 10, 35, read, 0 würde also bedeuten, daß die ACL mit der Objektnummer 300 dem Objekt 35 erlaubt, auf Objekt 10 die Aktion read durchzuführen.

Wenn man den Rest des Systems um diese Tabelle herum konstruiert, ist man bezüglich der Rechtevergabe nur durch das beschränkt, was man in das User Interface einbaut. Man kann theoretisch einzelnen Usern Rechte in Bezug auf einzelne Posts geben und nehmen und niederen Administratoren verbieten, an bestimmten Einstellungen herumzufummeln. Man könnte sogar bestimmten Teilen der Website den Zugriff auf bestimmte andere Teile untersagen.

Allerdings hat mein System einige Nachteile:
- Es ist nicht so extrem übersichtlich. Da alle Objekte in der selben Tabelle erfaßt sind muß man irgendwoanders die ganzen Metadaten oranisieren. Außerdem kann man nicht mehr anhand des id-Feldes erkennen, der wievielte Post ein Post nun ist, etc.
- Es ist auch nicht so extrem performant. Die Objekttabelle wird sehr schnell anwachsen, da jeder Scheiß da eingetragen wird.
- Außerdem muß die Seite haufenweise Datenbankanfragen stellen, um in Erfahrung zu bringen, was ein Objekt nun darf und was nicht. Vielleicht könnte man da mit stored procedures was reißen, aber so oder so bleibt einiger Overhead.
- Nicht zu vergessen, daß man die ganzen Abfragen auch alle coden muß.

Ist eben nur ein kleines Gedankenexperiment, um zu sehen, wie man ACLs auf die Spitze treiben kann.

[Xardas der Dunkle]

Warum speicherst du die ganze Menge, ohwohl eine Untermenge ausreicht? Warum hast du zwei Flags fuer ein und den selben Status?

...

Habe ich nicht. Das Flag verbieten hat eine höhrere Priorität als das Flag "Nein".
Wenn in einer Gruppe gesagt wird du darfst das in einer anderen du darfst es nicht darfst du es trotzdem.
Wird es hingegen verboten darfst du es wirklich nicht.

Ich habe es ja am Beispiel des Azubis versucht zu verdeutlichen. Ein Azubi in der Probezeit soll z.B. nicht direkt die Möglichkeit haben Artikel auf der Seite zu veröffentlichen, er darf aber neue Artikel anlegen und vieles mehr.
Würde ich sagen es gibt nur Ja und Nein müsste ich 2 Gruppen alle Berechtigungen zuweisen.
Bei meinem Vorgehen benötige ich zwar auch zwei Gruppen, nur brauche ich der Gruppe "Probezeit" nur eine Berechtigung zuweisen und zwar: "Veröffentlichen verbieten".



Diese Tabelle hat jetzt zwar echt etwas overhead nämlich das Feld record_class dieser ergibt sich aber durch das zugrunde liegende ORM und wird eig. erst wichtig wenn ich die Klasse Permission noch einmal ableiten würde.

Code:

--
-- Tabellenstruktur für Tabelle `xcms_permission_value`
--

CREATE TABLE IF NOT EXISTS `xcms_permission_value` (
  `id` int(12) unsigned NOT NULL AUTO_INCREMENT,
  `record_class` enum('Permission') COLLATE utf8_bin DEFAULT 'Permission',
  `name_id` int(12) unsigned DEFAULT NULL,
  `user_id` int(12) unsigned DEFAULT NULL,
  `group_id` int(12) unsigned DEFAULT NULL,
  `object_class` varchar(255) COLLATE utf8_bin DEFAULT NULL,
  `object_id` int(12) unsigned DEFAULT NULL,
  `value` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=21 ;

--
-- Daten für Tabelle `xcms_permission_value`
--

INSERT INTO `xcms_permission_value` (`id`, `record_class`, `name_id`, `user_id`, `group_id`, `object_class`, `object_id`, `value`) VALUES
(1, 'Permission', 1, NULL, 1, 'Sitetree', 2, 1),
(2, 'Permission', 1, NULL, 2, 'Sitetree', 2, 1),
(3, 'Permission', 1, NULL, 3, 'Sitetree', 2, 1),
(4, 'Permission', 1, NULL, 4, 'Sitetree', 2, 1),
(5, 'Permission', 1, NULL, 1, 'Sitetree', 4, 1),
(6, 'Permission', 1, NULL, 2, 'Sitetree', 4, 1),
(7, 'Permission', 1, NULL, 3, 'Sitetree', 4, 1),
(8, 'Permission', 1, NULL, 4, 'Sitetree', 4, 1),
(9, 'Permission', 1, NULL, 1, 'Sitetree', 5, 1),
(10, 'Permission', 1, NULL, 2, 'Sitetree', 5, 1),
(11, 'Permission', 1, NULL, 3, 'Sitetree', 5, 1),
(12, 'Permission', 1, NULL, 4, 'Sitetree', 5, 1),
(13, 'Permission', 1, NULL, 1, 'Sitetree', 6, 1),
(14, 'Permission', 1, NULL, 2, 'Sitetree', 6, 1),
(15, 'Permission', 1, NULL, 3, 'Sitetree', 6, 1),
(16, 'Permission', 1, NULL, 4, 'Sitetree', 6, 1),
(17, 'Permission', 1, NULL, 1, 'Sitetree', 7, 1),
(18, 'Permission', 1, NULL, 2, 'Sitetree', 7, 1),
(19, 'Permission', 1, NULL, 3, 'Sitetree', 7, 1),
(20, 'Permission', 1, NULL, 4, 'Sitetree', 7, 1);

[Jesus_666]

Habe ich nicht. Das Flag verbieten hat eine höhrere Priorität als das Flag "Nein".
Wenn in einer Gruppe gesagt wird du darfst das in einer anderen du darfst es nicht darfst du es trotzdem.
Wird es hingegen verboten darfst du es wirklich nicht.

...

Mit anderen Worten: "Nein" bedeutet "hat keine Erlaubnis". "Verboten" bedeutet "darf nicht, auch wenn er eine Erlaubnis hat". Das macht Sinn, weil ACLs in der Regel hierarchisch arbeiten, ein Objekt also die ACLs seiner Elternobjekte erbt. Ich kann also für das Elternobjekt eine Erlaubnis haben und für das Kindobjekt nicht – damit würde ich im Kindobjekt trotzdem Zugriff kriegen, sofern es nicht verboten wird.

Dabei "überstimmen" normalerweise Kinder- die Elternobjekte. Nehmen wir folgendes Szenario:

Code:

Foo (Zugriff erlaubt)
 +- Quux (kein ACL-Eintrag)
 +- Bar (Zugriff verboten)
     +- Baz (Zugriff erlaubt)
     +- Blubb (kein ACL-Eintrag)

Dann sehen meine Rechte so aus:
- Foo: Ich kann zugreifen.
- Quux: Ich kann zugreifen.
- Bar: Ich kann nicht zugreifen.
- Baz: Ich kann (theoretisch) zugreifen. Ich kann zwar nicht über Bar hinnavigieren, Direktzugriff könnte aber gehen.
- Blubb: Ich kann nicht zugreifen.

Falls man auf Objekte nur zugreifen kann, wenn man auch an die Elternobjekte kommt, so reicht ein Verbot irgendwo in der Kette der Eltern, damit ich keinen Zugriff mehr habe.