Rechtesystem

[paulbr]

Hallo Jens,

das Rechtesystem erscheint mir in der vorliegenden Art sehr kompliziert zu sein.
Zumindest kann ich mir im Moment noch kein Bild davon machen, wie das werden soll.
Access Control Management und jede Menge Relationen?
( CsGroups, CsRight, CsPermissions, CsRelGroupRight, CsRelUserRight, CsRelUserGroup )

Ich muss ehrlich sagen, so recht Blicke ich bei den rechten hier noch nicht durch 


Man könnte das doch mit 4 Tabellen (CsGroups, CsRights, CsPermissions, CsModules) lösen.

Ich hatte das mal vor einigen Jahren so gelöst:

Tabelle groups:    Administrator|Developer|Moderator|User
Tabelle rights:     #admin|#add|#change|#read

    #admin   = löschen, hinzufügen, ändern, lesen
    #add      =             hinzufügen, ändern, lesen
    #change =                             ändern, lesen
    #read     =                                        lesen


Tabelle modules:  -- beinhaltet die Module ---

Tabelle permissions:
                       permission_id | module_id | group_id | right_id

Beispiel-Eintrag für module_id = 1 (admin)
Eintrag in permission:
     INSERT INTO `permission` VALUES( 1, 1, 1, 1 );
     INSERT INTO `permission` VALUES( 2, 1, 2, 2 );

d.h. der Administrator hat #admin Recht an dem Modul: admin
      der Developer hat nur #add Recht an dem Modul: admin
      Grund: nicht das er den Administrator löscht 
      Gruppe: Moderator + User sind nicht eingetragen für dieses Modul, also keine Rechte.

Für die Rechte-Prüfung braucht man nur das Modul und die Gruppe des Users wissen,
dann kann man anhand der permission sehen welches Recht vorhanden ist.
Kein Eintrag in der permission = keine Rechte

Die Gruppe des Users wird in die Session mit abgelegt, beim öffnen des CC prüft man
welche Module-Rechte die Usergroup hat und zeigt im Menü entsprechend auch nur diese
Module an.

Bei Modulen wie: Useraccount, hier benötigt der User das Recht #change, damit er seine
Accountdaten ändern kann. Lediglich für seine Upload dateien benötigt er dann das Recht #admin.
Hierzu muss dann im modulename.controller.php entsprechend die Action mit dem Recht abgeprüft
werden.

Es braucht keine extra Klasse geladen zu werden und keine Relationen, lediglich die CsPermission
ist hier für das Recht zuständig. Ich denke die performance wird es danken 


gruss
paul

[xsign.dll]

Sieht stark nach OTRS aus - irgendwelche Hintergründe diesbzgl. ?

[paulbr]

Nein ist nicht OTRS, damit hatte ich mich bis dato noch nicht beschäfftigt.
Nein ich habe auch nicht die Absicht irgend etwas oder irgend jemanden zu kritisieren.

Mein Post resultierte aus dem Versuch das Login von Clansuite zu aktivieren, da ich für das frontend
welches ich nebenbei am basteln bin, die Templates für das Login + Registerformular angepasst hatte.
Da ist mir die komplexität aufgefallen.
Mal abgesehen davon das die Records dafür alle nicht korrekt benannt sind und jede Änderung
diesbezüglich in vielen Scripten und Relationen der Records angepasst werden muss.

Bei einem Rechtesystem gibt es kein vielleicht, sondern nur Ja oder Nein.

Meine Auffassung von einem Gruppen basierten Rechtesystem ist:
 - Bei einer Registrierung bedarf es keiner Rechteprüfung, da der User zu dem Zeitpunkt noch nicht Existiert.
 - Bei der Registrierung setzt man den User in eine default User-Gruppe, welche lediglich die "normalen"
   erlaubten Module Administrieren darf, z.B. seinen Account mit allem was dazu gehört.
 - Das Rechtesystem ist nur im CC von Wichtigkeit, es sei den, im öffentlichen Bereich sollen ebenfalls Module
   für bestimmte Gruppen ausgeschaltet werden können.
 - Der einfachheithalber unterscheidet man auch nach User CC und Admin CC, da die Anzahl der Rechteinhaber
   welche ein höheres Recht als die Masse hat, nur maximal eine handvoll beträgt.
   So hat der "normale" User von Anfang an nur seinen erlaubten Bereich in seinem CC.
   (auch die performance ist besser, da ja nur bestimmte Module geprüft und angezeigt werden)
 - Im Admin CC, wird geprüft ob die Gruppe das Recht hat, wenn Ja wird das Modul in der Navigation angezeigt,
   ansonsten ist es nicht vorhanden.
 - Innerhalb aller CC Modulen wird abgeprüft ob der zugreifende das hierzu nötige Gruppenrecht hat,
   falls er manuell die URL manipuliert um das Modul zu öffnen.

Anderst sieht es bei einem User basierten Rechtesystem, welches für ein CMS allerdings viel zu aufwändig ist.


Die Grundlage zu meinem letzten Posting
ist lediglich eine interpretation aus meinem vor ca. 12 Jahren programmierten wcms und den Erkenntnissen
diesbezüglich. Nur das es bei mir Namentlich Sektionen anstatt Module waren welche mit Rechte belegt wurden.

Ich hatte ebenfalls mit Relationen bei den Rechten gearbeitet.
Tabelle: group_rights(group_id|right_id) + group_users(group_id|user_id)

z.B. für den Adminbereich "Konfiguration" (Settings)
Tabelle: section
----------------------------------------------------------------
   category_id | parent_id |     name          |       title                 ........
----------------------------------------------------------------
       1000            null        config                 Konfiguration
       1001           1000       config.param        Seiten-Parameter
       1002           1000       config.metatags    Metatags
...

Tabelle: rights
----------------------------------------------------------------
   right_id | parent_id |      name                     |       title                 ........
----------------------------------------------------------------
       1            null         admin#admin                 Administration General (alle Rechte)
       2             1           config#admin                 Konfiguration (alle Rechte bei Konfiguration)
       3             1           config.metatags#admin    Metatags (alle Rechte)
...

Tabelle: groups waren dann der Administrator, sowie die Sektionsmodule z.B.
-----------------------------------------------
   group_id |          name
-----------------------------------------------
       1         Administrator
       2         Konfiguration (global)
       3         Konfiguration (Metatags)
usw...

in der Main-Page-Klasse:

Code:

...
$this->oNavigation = new CNavigation( 'navigation' );
// config
if ($iFeatureRights < 0) $fShow = true;
else {
   unset( $aRechte );
   $aRechte[] = 'admin';
   $aRechte[] = 'config';
   $aRechte[] = 'config.param';
   $aRechte[] = 'config.metatags';
   ...
   foreach ($aRechte as $sRight)  {
      if ($oUser->Right( $sRight, 'read' )) {
         $fShow = true;
         break;
      }
   }
}

if ($fShow) $this->AddNavigation( $this->oNavigation, 'a_config' );
...

in der Menünavigation dann wie folgt:

Code:

...
$sSection = $oApp->GetParameter( 'section' );

# Berechtigungssystem in config.php aktiviert?
$iFeatureRights = $oApp->GetFeature( 'user', 'rights' );

$oModule = new CNavigation( 'module', 'menu' );

switch( $sSection )
{
    # Section Konfiguration
    case 'config':
          ...
          $sSubSection = 'metatags';
          if ( $iFeatureRights < 0 || $oUser->Right('admin', 'admin' ) || $oUser->Right( "$sSection.$sSubSection", 'read' ) )
          {
             $sParent = $oPage->AddNavigation( $oModule, 'a_metatags', '', "section=$sSection&subsection=$sSubSection" );
             $oPage->AddNavigation( $oModule, 'a_meta_contenttype', $sParent, "section=$sSection&subsection=$sSubSection" );
             $oPage->AddNavigation( $oModule, 'a_meta_audience', $sParent, "section=$sSection&subsection=$sSubSection" );
             $oPage->AddNavigation( $oModule, 'a_meta_cachecontrol', $sParent, "section=$sSection&subsection=$sSubSection" );
          ...
}

// menu aktivieren und ausgeben
$oModule->SetView( $oApp->GetParameter( 'menu' ) );
$oModule->OutputTpl( $oPage->oTpl );
...

1. zuerst wird geprüft ob das Rechtesystem generell Aktiviert ist
2. hat der user für diese Sektion generell #admin Recht oder zumindest #read Recht
3. definieren des Menüs mit seinen Untermenüs für diese Sektion
4. navigation ins Template ausgeben

Vor ein paar Jahren habe ich für einen Kunden das wcms individuell angepasst, dafür hab ich dann u.a. das
bestehende Rechtesystem in der Form, wie ich es im letzten Post erwähnte, abgeändert.
Die vereinfachung und das wegfallen der Relationen steigerte die performance, auch die Fehleranfälligkeit war
geringer. Ein Verwalten der Rechte <=> Gruppen <=> Module ist ebenfalls vereinfachter.

Wie gesagt mein Post ist nur eine Sichtweise aus meinen Programmierungen und dem im Ansatz vorhandenen
Rechtesystem in der Clansuite, soweit ich da Einblick habe.

Also nichts für ungut für die Darstellung bezüglich meiner Interpretation eines Rechtesystems
und dem riesen Post.

Nochmals: Es liegt mir fern irgend jemand oder irgend etwas zu kritisieren,
auch bin ich kein profi der alles besser weiss und besser kann, mein Post soll lediglich
dem Gedankenaustausch und dem Verständnis dienen.


gruss
paul

[xsign.dll]

Hi Paul,

die Frage nach den Hintergründen zielte nicht in Richtung flamen ;-)

Ich war nur neugierig.

[paulbr]

Hallo xsign,

habe ich auch nicht als solches aufgefasst, ich wollte nur nicht das Gefühl
aufkommen lassen, da ich ja mit meinen post's schon einige Dinge von mir gab.

Ich denke ein Forum ist dafür da verschiedene Ansichten und Aspekte darzustellen.
So kann man unter Umständen bessere oder simplere Lösungen mit gleichem oder
besseren Ergebnis erarbeiten.

Ich gebe zu, ich drücke mich nicht immer klar aus indem was ich meine, das liegt
aber wohl daran, das vieles nicht einfach wieder zugeben ist und ich bestrebt bin
in einem öffentlichen Forum so zu schreiben, damit es möglichst jeder der das liest
verstehen kann.

Ich denke das dieses Forum nicht nur von Experten in Sachen Programmierung gelesen wird,
sondern wohl eher überwiegend von Personen (semi Profis wie ich), welche die Clansuite
entwicklung mitverfolgen weil sie die Idee klasse finden und das Clansuite irgendwann gerne
einsetzen möchten  

Zu den Milestones und der release sag ich mal nichts, den da gehen die Meinungen eh auseinander.
Nur soviel: Was muss ein Clansystem den haben für ein erstes Alpha-Release?
 - Funktionierender Core
 - News
 - Forum
 - Accountverwaltung
 - einige frontends zur Auswahl
 - evtl. Gästebuch (aber kein muss)

damit kann ein Clan seine Member zum Anfang schonmal etwas bieten.
Man muss ja nicht gleich von Anfang an Clan's berücksichtigen, welche 100
oder mehr Usern haben. Ein kleiner Clan braucht für den Start nicht viel nur eine Alpha.
Nicht jeder Clan benötigt den kompletten Umfang wie er hier für Clansuite geplant ist.
Ich weiss von vielen Clan's die lediglich Ihren Membern ein Portal mit News und einem Forum
bieten möchten.

Wie ist den der Stand der Clansuite nach diesem Aspekt?
Es fehlt doch nur noch ein funktionierendes Rechtesystem, dann kann man bereits
Clansuite einsetzen.

Andere Module wie:
 - Galerie
 - Teamspeak
 - Games
 - Matches
 - Redaktionssystem
 - Bridges zu anderen Foren
 - Clankasse
 - etc.

folgen dann additiv mit fertigstellung der Module.


gruss
paul

[Jens-A. Koch]

Hallo,

das von mir angedachte Rechtesystem entspricht "teilweise" dem Standard RBACL.
Ich habe mich dabei an phpGACL und pearLiveuser orientiert
Wir hatten in den Anfangstagen der Entwicklung schonmal eine Diskussion zu diesem Thema.
Dort hab ich beschrieben, wie ich mir ein erweiterbares Rechtesystem vorstelle.
Link zum Thread
Zu den Grundannahmen und auch zur Frage, woher die "vielen" Relationstabellen kommen &nbsp;möchte ich auf die Posts #2 und #6 verweisen.

Ausgangspunkt sind eine User- und eine Rechtetabelle.
Zwischen beiden besteht eine Relationstabelle (User2Permission).
Die Usertabelle liegt bereits durch die Accountverwaltung vor.
Damit ist bereits die einfachste Form eines Rechtesystems möglich.
Die Permissionstabelle enthält feststehende Bezeichner für die Rechteprüfung

Hinzu kommen Erweiterungen, so beispielsweise für Gruppen.
Für Gruppen sind 3 zusätzliche Tabellen erforderlich: Gruppen, User2Gruppe, Gruppe2Permission.
Bis zu diesem Punkt würde ich das gerne realisieren.

Nur das es bei mir Namentlich Sektionen anstatt Module waren welche mit Rechte belegt wurden.

Auch die Sammlung von Rechten unter einem Modul oder einem Core-Bereich kann man mit 2 Tabellen ergänzen: eine Tabelle für Bereiche/Module/Areas (wie auch immer man es benennt) und eine Relationstabelle für Permission2Area. Aber auch dies ist zusätzliche Komplexität - und man muss es nicht machen.

Um die Performance mache ich mir keine Sorgen, da man die ganzen Relationstabellen in eine Tabelle zusammenpacken kann. Damit entfallen joins über mehrere Tabellen. Natürlich ist die Tabelle in Teilbereichen neu zu generieren, wenn Veränderungen an Usern, Gruppen, Rechten vorgenommen werden. Dies entspricht im Ergebnis dem Ansatz von Paul, die Rechtetabelle aus Performancegründen gleich so aufzuziehen:

Tabelle permissions: permission_id | module_id | group_id | right_id

Hier könnte man auch noch andenken die Rechtedaten bereits serialisiert abzulegen, um sie ohne Umweg direkt als Teil des Sessionarrays zu verwenden.

Nun zu den Ideen bzw. Vorschlägen:

- Bei einer Registrierung bedarf es keiner Rechteprüfung, da der User zu dem Zeitpunkt noch nicht Existiert.
 - Bei der Registrierung setzt man den User in eine default User-Gruppe, welche lediglich die "normalen"
 &nbsp; erlaubten Module Administrieren darf, z.B. seinen Account mit allem was dazu gehört.

Also derzeit ist der User zum Zeitpunkt seiner Registrierung bereits User der Gruppe "Gast" fest zugewiesen. Nach Registrierung erhält er die Nutzergruppe "Registrierter Nutzer".
Die Rechte sind somit auch für Gäste einstellbar - dabei gehts ja hauptsächlich um Sichtbarkeitsberechtigungen (view) des Frontends.
Aus Performance-Sicht ist schon die Eröffnung einer Gast-Session fraglich.

...mein Post soll lediglich
dem Gedankenaustausch und dem Verständnis dienen.

Genau darum geht es. Ich kann mich mit meinen Annahmen und Ideen auch gut irren und falsche Wege gehen - und andere können mit Ihren Vorschlägen durchaus Recht haben.
Es sollte hier aber immer möglich bleiben darüber zu reden und den Dingen gemeinsam auf den Grund zu gehen.

Der Thread wird bestimmt länger...

Soviel erstmal, Gruß Jens.

[paulbr]

Aus Performance-Sicht ist schon die Eröffnung einer Gast-Session fraglich.

Wird aber für die Statistik benötigt wieviele Besucher Online sind.


Mal Gedanken ordnen
Nicht registriert oder eingelogt bedarf es nur die Gruppe Gast, das ist soweit klar.
Als "normaler" member, nach dem login, bedarf es eigentlich nur einer standard gruppe
ohne speziellen userrechten (Gruppe "Member"), welche Internas auf der Webseite
lesen und seinen Account verwalten darf.

Einzig wenn ein Member mehr als nur den Standard machen darf/soll bedarf es einer
zuordnung mittels Speziellen Rechten.

Das heisst aber auch, das es sich hierbei ja nicht um die masse der member handelt,
das dies performance technisch gesehen nicht unbedingt eine Rolle spielt.
Solange die Prüfung der Userrechte sich auf dem Kreis beschränkt.

Man könnte dafür ja ein code in die session legen, das die Rechteprüfung eben nur dann
aufgerufen werden soll.

z.b.
       'g0' = gruppe "gast"
       'g1' = gruppe "normal" Member
       'g2' = gruppe > "normaler" Member

so kan man überall direkt erstmal handeln ohne Rechte querprüfung.
Wenn ein Modul Admin Rechte benötigt, muss der sessioncode 'g2' sein,
ist er das nicht, ist es auch kein Admin und hat keine change das Modul zu öffnen.

Im falle das der sessioncode 'g2' ist, wird die entsprechende Prüfung gestartet.
Hier würde dann auch erst das von dir angesprochene Rechtesystem greifen.

Eine Manipulation der Session von 'g0' auf 'g2' bringt keinen schaden, da in diesem Fall
ja die Prüfung des Rechtesystems anspringt.

Habe ich das soweit richtig interpretiert?

gruss
paul

Nachtrag:
  Wenn man es nach dieser Art erstellt, so könnte man eigentlich jetzt schon
  die Einteilung in oben genannten 3 gruppen machen und das login freigeben.

  Für die Gruppe Admin lässt man ebend im momemt alles frei wie jetzt auch,
  die Rechtebeschränkung mittels RBCAL betrifft dann ja nur die Admingruppe.
  Gruppe 'Gäste' und Gruppe 'normal Member' währen davon ja nicht betroffen.
 

[paulbr]

Ich habe mir die Tage mal wieder Gedanken um die Rechteverwaltung gemacht.
Es sollte so einfach wie möglich, aber doch effizient und flexibel sein.

Primär werden in meinem Modell Gruppenrechte festgelegt.
Sekundär, wenn erforderlich, könnten noch User-Rechte vergeben werden.

Im Anhang mal ein Beispiel der Tabellen und der Administrationsmöglichkeit anhand des Modules: Index.
Die User-Overflow Tabelle für spezielle Modulrechte hab ich nicht im Anhang berücksichtigt,
ist aber Equivalent zur cs_acl_ressources nur eben statt Gruppe dann user_id.

Core: Clansuite_ACL

• Auslesen und Rückgabe der Modulrechte
• z.B. Clansuite_ACL::getModulePermission($modulname)
• z.B. Clansuite_ACL::getModulePermissionOverflow($modulname)

Clansuite_Modul_ACL , welche die Rechte Verwaltet

• Datensätze anlegen, ändern, löschen für ACL-Tabellen gem. Anhang

Clansuite_Module_Controller

• Gruppen-Rechte für dieses Modul auslesen und anwenden
• Prüfen ob der User Overflow- Rechte hat, welche die Gruppen-Rechte überschreiben

Wenn keine Rechte vorhanden sind dann Redirect zur Startseite.

Für das Forum wird keine spezielle ACL_Gruppe benötigt, der Moderator ist ja Admin oder Member.
Moderatoren-Rechte werden im Modul: Forum dann eigenständig verwaltet.
Es reicht einen Member entsprechend als Moderator anzulegen.

Im Anhang ebenfalls die dafür notwendige Änderung in der cs_group.
So wird automatisch die Gruppe der acl_role zugeordnet.
Um hier einen zusätzlichen Datenbank Zugriff zu umgehen, sollte man die role_id ebenfalls
in die Session schreiben.

2 Zusätzliche Gruppen machen Sinn:

• root (mit allen rechten)
  Einen Superadmin gibt es nur einmal, wogegen Admins durchaus mehrere existieren können.
  Ein Admin sollte aus Sicherheitsgründen keine Supervisor Rechte haben.
• bot
  Suchmaschinenbots sollten nicht als Gast definiert werden.
  So kann man zum einen Spezielle Bereiche, welche ein Gast sehen darf, aber Suchmaschinen evtl.
  nicht sehen sollen, ausklammern.
  Auch ist es für die Statistik von Vorteil wenn man hier Unterscheiden kann.
  Kann eine neue Klasse im user.core.php sein, z.B. Clansuite_BotUser.

Die Tabellen: cs_areas | cs_groups_rights | cs_rights | cs_rel_group_rights | cs_rel_user_rights
würden dann nicht mehr benötigt werden.


Tabellen für Module
Ebenfalls im Anhang mit reingepackt mal eine überarbeitet Version der cs_module.
Hab diese etwas abgespeckt, da einige Felder meines Wissens nirgendwo benötigt werden.
Die Submodule welche eine eigene Tabelle belegen werden eigentlich nicht benötigt.
Zusammengehörigkeiten der Module kann man auch mittels Sections lösen.

z.B.
module_id: 100
name: account
section: 2 (system)
parent_id: 0
…

module_id: 181
name: profil
section: 2 (system)
parent_id: 100
…

Zusammengefasst werden die Module im Adminbereich unter den Sectionen, darin zugehörig die Child-Module.
So kann man Die Module Optisch trennen und benötigt 2 Tabellen weniger.

Die Tabellen: cs_mod_rel_sub | cs_rel_category_module | cs_submodules würden entfallen
Dafür kommt die cs_modules_section hinzu.

Bitte mal anschauen ob dieser Ansatz brauchbar ist und keine all zu vielen Denkfehler enthält.

Gruss
Paul

[paulbr]

Nachtrag:

im Anhang ein Beispiel für die Umsetzumg der ACL.

Zu Testzwecken:
Eintrag in clansuite_loader -> function autoloadInclusions()
'Clansuite_ACL' => ROOT_CORE . 'acl.core.php',

Eintrag in Clansuite_CMS -> function register_DI_Core()
'Clansuite_ACL',

Die acl.core.php nach clansuite/core kopieren.

Das Modul: Index hab ich mal individuell auf das vorgeschlagene ACL abgeändert.
Vorher bestehende daten umbenennen/sichern.
Dies betrifft: controller/index.module.php + view/smarty/action_show.tpl

Die Tabellen aus dem vorherigen Post beinhalten die ACL für das Modul: index.
Im Ordner /_sql liegt eine acl.sql zum updaten der clansuite DB.
Die SQl renamed die 2 für den Test geänderten tabellen: cs_groups + cs_modules.

Nach abschluss des tests dieneu Importierten Tabellen wieder löschen und die gesicherten tabellen wieder zurück umbenennen.
Die ACL records liegen im Ordner /myrecords.

gruss
paul

[Jens-A. Koch]

Hallo,

Suchmaschinen/Bots
Diese Idee ist neu. Sehr schön. Das setzt voraus, dass wir Abfragen, um welchen "Browser" / "Client" es sich handelt und dann ein entsprechendes User-Objekt initialisieren.

Für die Browsererkennung stehen die folgenden Klassen zur Verfügung browscap (/libraries/browscap) und phpSniff (/libraries/phpSniffer).
Browscap holt sich die aktuellen Clients übers Netz (http://browsers.garykeith.com/stream.asp?BrowsCapINI) - später dann einfach Browscap->getBrowser().
Die Liste im Sniffer ist hingegen manuell zu updaten - dürfte inzwischen etwas out-of-date sein, denn es kommen ja immer wieder neue Bots hinzu.

Module/Submodule
Grundsätzlich wäre es günstiger die Tabellen Module und Submodule zu behalten,
denn diese Dinge existieren ja tatsächlich. Mit anderen Worten, die Tabellen bilden ja nur ab, was es auch im Dateisystem gibt.
D.h. es gibt eine 1:1 Relation von news.module.php auf die Tabelle Modules und eine 1:n Relation von news.xy.php auf die Tabelle Submodules.
Zwischen beiden Tabellen besteht wieder eine 1:n Relation, den ein Modul kann beliebig viele Submodule haben.

Die Tabellen sollten wir ausmisten - da hast Du vollkommen Recht.
Eigentlich reicht "id" und "name". Der Rest kann über die info-Datei gelesen werden.

Die Tabelle "cs_rel_category_module" wird benötigt, wenn ein Module Kategorien ablegen möchte (module 1:n cats). Das haben wir damals eingeführt, damot nicht jedes Modul einen eigenen Categories Table führen muss.

Die angesprochene Tabelle cs_modules_section wäre letztlich cs_areas, oder?

Also Ideen sind ja definitiv genügend da. Die angesprochenen Dinge betreffen alle den Milestone 0.2.4 (Rechtesystem). Hier mein Vorschlag für einen Arbeitsplan:

1. User-Login
- als neuer User anmelden
- einloggen
- eingeloggt bleiben (session cookie)

2. User-Verwaltung
- user manuell anlegen
- löschen
- profil editieren
(- rechte editieren (siehe 5.))

3. Gruppen-Verwaltung (cs_groups)
- create, read, update, delete
- permissions einer gruppe zuweisen und entfernen

4. Rechte-Verwaltung (cs_permissions)
- create, read, update, delete
- automatisches create (d.h. befüllen des permission tables mit den verfügbaren actions pro modul mittels reflection. dieses verfahren brauchen wir mehrmals, so auch beim routing, da man sonst die endpunkte/action manuell einpflegen muss! hier wird die relation zur tabelle cs_modules gebraucht (id/name).

5. User-Rechte editieren (Relationen herstellen)
- User eine Permission zuweisen und entfernen - cs_rel_user2permissions
- User eine Gruppe zuweisen und entfernen -cs_rel_user2group

Soviel erstmal, Jensa

[paulbr]

Für die Browsererkennung stehen die folgenden Klassen zur Verfügung browscap (/libraries/browscap) und phpSniff (/libraries/phpSniffer).

Ich dentiere da lieber zu browscap.

Module/Submodule
Also entweder steh ich auf der Leitung oder hab Clansuite noch nicht so richtig kapiert.
Meines Erachtens sind viele Splittungen unnötig und verursachen zuviel Serverlast.
Das mag alles reichen bei bis zu 40-50 Usern/Besucher zeitgleich, darüber ist die Serverlast
viel zu hoch, entweder kann der Besucher Kaffee trinken gehn bis die Seite aufgebaut wird (time limit 0),
oder er bekommt eine to busy Fehlerseite angezeigt.
Nicht jeder der Clansuite mal einsetzen wird, verfügt über einen schnellen Root-Server.
Ich hatte das Problem bei einem Auktionshaus Projekts, da sind in spitzenzeiten teilweise
bis zu 2000 Besucher zeitgleich auf den Seiten. Die DB Zugriffe waren eminent hoch, es mussten
hier viele änderungen durchgeführt und zudem noch auf 3 Servern geclustert werden um die Last zu verteilen.
Application-Server, Datenbank-Server, Search-Server. Wobei aus Serverlastgründen die DB vom DB-Server
sogar noch auf dem Search-Server gespiegelt werden musste, um die Zugriffe vom DB-Server zu nehmen.

Gut ich denke nicht das eine Clanseite mehr als 50 User zeitgleich auf den Seiten haben wird, trotzdem sollte
man dies in betracht ziehen und entsprechend gestalten.

Grundsätzlich wäre es günstiger die Tabellen Module und Submodule zu behalten,
denn diese Dinge existieren ja tatsächlich. Mit anderen Worten, die Tabellen bilden ja nur ab, was es auch im Dateisystem gibt.

Ich kann das doch in einer Tabelle ebenfalls darstellen.

Beispiel: 1 Tabellen Nutzung
Modul <-> Submodul aus aktueller DB:
----------------------------------------------------------
modul-id  name              parent_id
----------------------------------------------------------
1            account           0
2            admin              0
..
35          profil                1
36          guestbook         1
37          general             1
38          computer          1
40          admin               2
41          configs             2
42          modules            2
43          users               2
44          usercenter        2
45          groups             2
...

Aktuell: 3 Tabellen Nutzung
Tabelle: cs_module
-----------------------------------
id   name
-----------------------------------
1    account
2    admin
...

Tabelle: cs_submodule
-----------------------------------
id    name
-----------------------------------
1     admin
2     configs
3     modules
4     users
5     usercenter
6     groups
...
70   profile
124 guestbook
125 general
126 computer

Tabelle: cs_mod_rel_sub
-----------------------------------
module_id  submodule_id
-----------------------------------
1               70
1               124
1               125
1               126
2               1
2               2
2               3
2               4
2               5
...

Wo ist den hier der Unterschied zu dem vorhandenen, ausser das man nur 1 tabelle anstatt 3 benötigen würde.
Name ist unique ok da muss man aufpassen das Modul und Submodul nicht gleich heissen, aber
das ist doch nicht das Problem.
Dazu kommt das es das modul: admin in dieser Form wie aktuell in den tabellen abgebildet nicht existiert.
Das wurde in Modulen: modulemanager | templatemanager | thememanager | settings .... aufgeteilt.
Der jeweilige File- und Classname welcher in der Tabelle eingetragen ist, wird meines wissens nicht
benötigt, da dies der controller erledigt anhand des links.

Momentan wird es doch nur unnötigerweise aufgebläht, auch wird es komplizierter in der Rechtevergabe.
Rechtevergabe soll ja Modulbezogen sein. d.h. Gruppen/Userrechte werden auf Modulen gelegt.
Da ist es doch performanter wenn alles in einer Tabelle abgebildet ist. So übermässig gross wird die
Module-Tabelle deshalb trotzdem nicht werden.
Auch kann der Modulemanager somit entlastet werden, er braucht keine 3 tabellen zu aktualisieren,
bei änderungen bzw. erstellen von neuen Modulen.

Die angesprochene Tabelle cs_modules_section wäre letztlich cs_areas, oder?

Die sections sind quasi categories unter denen zusammengehörige module angezeigt werden können.
das kann sowohl im Adminbereich als anderweitig z.b. Menü verwendet werden.

Auch sections sind wie categories unterteilbar.
z.b.

ID     Name         Parent-ID
1      System
100   Settings      1
101   global         100
102   metatags    100
...

Das heisst ich hab eine Area: System in dem ich Subs-Areas habe, beim anzeigen kann man das nun wie
levels ansehen. Ein Modul kann die section: System haben oder auch einer Subsection zugeordnet werden,
spielt keine Rolle, angezeigt wird es immer unter der Haupt-Sektion.
Ich setze z.b. Sektions im Administrationsbereich ein.
Wenn ein User kein Recht hat Module aus der Sektion: System anzuschauen, geschweige den zu ändern,
wird dieser Sektionsblock mit seinen Subsektionen erst gar nicht angezeigt.

Sektionen verwende ich um Module zu Katalogisieren, während Kategorien dazu dienen, Artikel, Seiten oder
anderes zu Katalogisieren.

Nach diesem System brauch ich keine Relationen, die unnötig Serverlast verursachen.
Die Kategorientabelle ist bei mir ebenfalls wie die Sektionstabelle unterteilbar.
Es gibt Hauptkategorien innerhalb denen viele childs-kategorien Möglich sind.
z.b.
hauptcat 1
   subcat 1.1
      subcat 1.1.1
         subcat 1.1.1.1
            subcat 1.1.1.1.1
         subcat 1.1.1.2
      subcat 1.1.2
   subcat 1.2
hauptcat 2
...

Rechtesystem

Also Ideen sind ja definitiv genügend da. Die angesprochenen Dinge betreffen alle den Milestone 0.2.4 (Rechtesystem). Hier mein Vorschlag für einen Arbeitsplan

Die Punkte 1-3 sind soweit klar.

Punkt 2: (rechte editieren) entspricht die userrechte in meinem vorgestellten ACL-Model.
Punkt 3: (permissions einer gruppe zuweisen und entfernen) ist ebenfalls in dem ACL-Model vorhanden.

4. Rechte-Verwaltung (cs_permissions)
- create, read, update, delete

Im ACL-Model vorhanden.

4. Rechte-Verwaltung (cs_permissions)
...
- automatisches create (d.h. befüllen des permission tables mit den verfügbaren actions pro modul mittels reflection. dieses verfahren brauchen wir mehrmals, so auch beim routing, da man sonst die endpunkte/action manuell einpflegen muss! hier wird die relation zur tabelle cs_modules gebraucht (id/name).

Das hab ich nicht ganz verstanden.

Ich gehe in dem ACL-Model davon aus:
das im modulecontroler.core.php die permission auf das Modul geprüft wird,
bei action: view = 0 (webseite) erfolgt ein redirect auf die homeseite, da der user keine berechtigung für dieses
Modul hat.
bei action: manage = 0 (adminbereich) wird im bestenfall das Modul erst gar nicht zum administrieren angezeigt
wenn doch, oder wenn der user in der URL rumspielt und möglichkeiten ausprobiert, erfolgt ein redirect auf die Admin homeseite,
da der user keine Berechtigung für dieses Modul hat.

View-Rechte werden 2 benötigt:
  - View auf der Webseite (ACL-Model: action = view)
  - View im Adminbereich (ACL-Model: action = manage)

Macht das nicht mehr Sinn diese nur bei Bedarf, also wenn ein Modul aufgerufen wird zu Prüfen?

Ausnahme ist hier das Menü.
Aber das Menü kann ja speziell die view-permission über eines bestimmten Modules mittels
clansuite_acl abfragen, wenn erlaubt dann anzeigen, ansonsten nicht.
Die permissions werden wie die $config ja nicht permanent neu ausgelesen, sondern im cache gehalten.

In dem ACL-Model existiert ein default permission array:
$perms = array(
    'view'         => 0,
    'manage'   => 0,
    'add'         => 0,
    'edit'         => 0,
    'delete'      => 0
);

In diesem werden nun durch Angabe des Modulnamens die Berechtigung der Gruppe und User
die actions aktiviert wenn sie in der rules tabelle eingetragen sind, also aktiviert sind.
In der rules tabelle sollten im normalfall nur access=1 einträge sein.
d.h. wenn eine permission entfernt wird, wird diese aus der rules-tabelle entfernt, wird eine
aktivieret, wird diese in die rules mit access=1 eingetragen.
Um die Permission für ein Modul zu bekommen, benötigt man nur die Angabe des Modulnamens
und der role-id, welche gruppenabhängig ist und in der session steht.
Also ist alles was actionname = 1 ist erlaubt.
Um auch noch falls benótigt, angepasste userrechte zu bekommen,
muss man nur zusätzlich die user_id mit übergeben (default ist ohne user_id).

Wie gesagt irgendwie hab ich wohl das von dir erwähnte umsetzen des Rechtesystem nicht ganz
verstanden und anderst Interpretiert.

gruss
paul

[paulbr]

Nachtrag:

- automatisches create (d.h. befüllen des permission tables mit den verfügbaren actions pro modul mittels reflection.

meintest du damit, das erstmalige anlegen der gruppenrechte?

Das kann doch bei der Clansuite Installation erfolgen.
Man legt eine default permission ini (jederzeit änderbar vor der Installation durch den installierenten)
an, in der man zuordnet, welche gruppe welche standard modulrechte haben soll.
Beim Installieren werden diese dann direkt schon in den rules eingetragen, oder man erstellt einen
default sql dump für die permission und importiert diesen bei der Installation.
Es wird immer erforderlich sein, das der jeweilige Admin für seine Clanseite diese im Modulmanager
überarbeitet, da jeder seine eigenen Vorstellungen hat wer was darf und was nicht.

Der Modulemanager ist ansonsten für die feinarbeiten Modul <-> Gruppenrecht zuständig.
In der Userverwaltung kann man manuel einem user von der gruppe abweichende Rechte
an einem/mehreren Modulen geben.
Arbeitsweise wie bei der Rechtevergabe im Modulemanager nur ebend User- anstatt Gruppenbezogen.

Beim Installieren neuer Module, kann man ja eine module.acl.ini einlesen bzw. die module.config
entsprechend um die gruppen permissions erweitern.
[acl-grp-1]
view=1
manage=0
..
[acl-grp-2]
..

So können die Gruppenrechte beim Installieren eines Modules bereits im permission formular vorgegeben werden.
Da gibt es viele Ansatzmöglichkeiten wie man das gestalten kann.

Der Punkt 4 deines Posts ist mir absolut unklar wie du das meinst.
Warum wird befüllen des permission tables mit den verfügbaren actions mehrmals benötigt?
Es braucht doch nur einen Eintrag in den Regeln, wenn ein action aktiviert wurde.
Dies wird im Modulemanager bei dem Modul-Zugehörigen permissions per checkbox aktiviert oder
deaktiviert (siehe pdf aus meinem post, ist ein bild vom adminbereich wie es ausschauen könnte drinnen).

Arbeitsweise der Clansuite_ACL aus dem vorgestellten Model:
Die function: getModulePermission($modulname, $roleid, $userid = 0)
Arbeitet 4 schritte ab:
  1. Holen der actions für das übergebene Modul ($modulname)
  2. Holen der aktivierten Gruppenrechte für das Modul ($roleid)
  3. Wenn $userid angegeben wurde, holen der abweichenden userrechte zu dem Modul
      (ist optional, weil ja nicht jeder unbedingt userrechte benötigt, die meisten werden
      nur mit Gruppenrechte arbeiten, so hat man keinen unnötigen performance verlust)
  4. Rückgabe des permission-Array's

Das permission array hat immer diese struktur:
$perms = array(
    'view'       => 0,
    'manage'   => 0,
    'add'        => 0,
    'edit'        => 0,
    'delete'     => 0
);

Wenn das gruppen- oder userrecht nur eintrag auf view hat, schaut das Rückgabe-Array so aus:
$perms = array(
    'view'       => 1,
    'manage'   => 0,
    'add'        => 0,
    'edit'        => 0,
    'delete'     => 0
);

Damit hat man alle Informationen bzgl. der Rechte an einem Modul die man benötigt,
mit aufruf nur einer einzigen Funktion, egal wo man die nun benötigt.

gruss
paul

[Jens-A. Koch]

Hallo Paul,

Danke für die umfangreichen Diskussionbeiträge und die Arbeit und Zeit, die Du reinsteckst. Wenn Du das schon teilweise umgesetzt hast, dann kannst Du das gerne ins SVN einfügen!
Was wirklich zählt ist, was im SVN ist.

Ich kann mich mit meinen Annahmen zum Rechtesystem auch gut irren und falsche Wege gehen - und Du kannst mit Deinen Vorschlägen und aufgrund der Erfahrungen mit dem Auktionshaus durchaus Recht haben.

1. Bot/Suchmaschinen/Browsererkennung mittels Browscap. Sniffer werf ich raus.

2. Ich denke der Unterschied zwischen dem Verfahren mit Relationstabellen und ohne liegt darin, dass die Struktur mit Relationstabellen teuer in der Select-Abfrage ist, billig beim Insert.
Während die Struktur mit zusammengefassten Tabellen in der Select-Abfrage billig ist und beim Insert teuer. Ich stelle mir vor, mit Relationen und einfachen Inserts zu arbeiten und dann einen Caching-Table über die Tabellen zu bilden (dann entfallen joins).

Struktur und Relation gehen vor Caching-Table und Optimierung.
Im Bereich Datenbank geht noch einiges: InnoDB, automatische Indextabellen, storedProcedures, storedViews, Query-Caching. Wir haben quasi nichts davon im Einsatz!

Dein Verfahren, also gleich mit zusammengefassten Tabellen zu arbeiten, geht natürlich auch.
Die zusammengefassten Tabellen verstecken aber eher die Relationen, als sie zu offenbaren.
Diesen Nachteil sieht man, wenn man sich das Datenbank-Schema dann mal grafisch visualisiert ansieht.
Nur mal als Beispiel das ACL von Joomla 1.6:

Hier wurden zusätzlich Asset-Tabellen und Relationen eingefügt, um Dateien und Bilder in das Rechtesystem einzubeziehen. Mit anderen Worten: es ist Standard, Dinge die im Filesystem zu finden sind, auf die entsprechenden Rechtetabellen abzubilden (Modul, Submodul, Action, Dateien).

3. Serverlast
Das Problem ist mir bewusst. Fakt ist, es wird erstmal nur schlimmer... denn selbst mit zusammengefassten Tabellen kommen noch Abfragen hinzu.
Ein komplexes Rechtesystem ist nicht unbedingt zu verteufeln, weil es nochmal Performance frisst.
Vielmehr eröffnet es sehr flexible Möglichkeiten.

4. cs_permissions oder cs_rights (die Tabelle für die einzelnen Rechte)

automatisches create (d.h. befüllen des permission tables mit den verfügbaren actions pro modul mittels reflection. dieses verfahren brauchen wir mehrmals, so auch beim routing, da man sonst die endpunkte/action manuell einpflegen muss! hier wird die relation zur tabelle cs_modules gebraucht (id/name).

Zur Erklärung: Ich gehe in meinem Ansatz davon aus, für jede aufrufbare Action eine Berechtigung in die cs_permission einzutragen. D.h. man nimmt ein Modul und scannt die verfügbaren Actions und trägt diese als "Einzel"rechte ein. Das kann man zwar manuell machen, beispielsweise über eine Beschreibungsdatei, aber über Reflection gehts einfacher.
Nachdem diese Einzelrechte in cs_permissions eingetragen wurden, kann man in cs_groups diese Rechte unter dem Modulnamen zusammenfassen (Gruppierung von Rechten).

Der Herkunftsort für die Rechte bei Deiner Variante ist in einer Beschreibungsdatei.

Beim Installieren neuer Module, kann man ja eine module.acl.ini einlesen bzw. die module.config
entsprechend um die gruppen permissions erweitern.
[acl-grp-1]
view=1
manage=0
..
[acl-grp-2]

Du gehst von 5 statischen Rechten aus: 'view' ,'manage','add','edit', 'delete' (VMAED), die in einem Modul vorkommen können. Wir hatten das früher auch so, da gab es 3 Modultypen:
CRUD (create, read, update, delete)
BREAD (browse, read, edit, add, delete)
ABCD (add, browse, change, delete)
Dabei mussten die Endungen der Actions immer stimmen. Irgendwie hat die Erfahrung gezeigt, dass man damit nicht hinkommt. Fürs Scaffolding bzw. Bausteinprogrammierung mag es dem Entwickler helfen. Er hat dann schonmal 5 Methoden, die er befüllen kann.
Aber es gibt immer Actions die anders benannt sind/werden müssen und aus dieser Konvention rausfallen, beispielsweise auch der Zugriff auf Downloads (Bilder/Dateien). Wenn man hier korrekt sein möchte, müsste man dafür eine Tabelle cs_assets oder cs_files anlegen und die Dateien einfügen, um sie anknüpfbar für eine Rechtevergabe zu machen.

Ich werde den Scanner für die Actions auch an anderen Stellen im System einsetzen, so beispielsweise bei der
- Menupünkte-Verwaltung. Hier werden alle verfügbaren Actions pro Modul in Baumstruktur angezeigt und man kann sie ins eigene Menü verschieben / ein eigenes Menu zusammenstellen.
- Verwaltung und Erstellung von Routingregeln. Hier sind insbesondere die GET Parameter wichtig, die ebenfalls erfasst werden. Derzeit gehen keine Routings mit zusätzlichen Parametern.

Nochmals: wenn Du schon etwas geschrieben hast, dann rein damit ins SVN.

Gruß Jens

[paulbr]

Zur Erklärung: Ich gehe in meinem Ansatz davon aus, für jede aufrufbare Action eine Berechtigung in die cs_permission einzutragen. D.h. man nimmt ein Modul und scannt die verfügbaren Actions und trägt diese als "Einzel"rechte ein.

Ich glaube wir denken im Prinzip in groben Zügen das gleiche, es ist wohl nur: Welchen namen gebe ich meinem Kind.

Das ACL-Model ist ja nur ein Gedankenspiel und um es sich besser Vorstellen zu können,
hab ich es mal auf die schnelle ganz grob umgesetzt.
Das ist auf gar keinen Fall eine im detail durchdachte Endlösung, sondern nur ein Anfang um mal eine
einheitliche Arbeitsgrundlage zu erarbeiten, nennen wir es mal brainstorming 

Das hier vorgestellte permission dient nur der verdeutlichung, es kann auch anderst sein.
Anstatt die actions fix zu benennen welche, und da gebe ich dir recht, mitunter anderst heissen
können, kann man diese auch flexible gestalten.

z.B. anstelle von:
$perms = array(
    'view'       => 0,
    'manage'   => 0,
    'add'        => 0,
    'edit'        => 0,
    'delete'     => 0
);

Kann es auch sein:
    'admin_edit'         => 0,
    'admin_edit_info'   => 0,
    'admin_install'       => 0,
    'admin_export'      => 0,
    'admin_imexport'   => 0
   ...

nur um mal einige der actions, hier aus dem Modul: modulemanager zu nennen.
Das scannen kann eingeschränkt werden, wenn man die actions in der config des jeweiligen Modules
definiert.

z.b. section:
[actions]
;action-name      permission (grp1|grp2|grp3...)
admin_edit         = "1|1|0|0|0..."
admin_edit_info  = "1|1|0|0|0..."
admin_install      = "1|1|0|0|0..."
admin_export     = "1|1|0|0|0..."
admin_imexport  = "1|1|0|0|0..."
...

ob man nun die rechteangabe hier als default bereits angibt oder nicht
kann man zur gegebenen zeit noch entscheiden.
man braucht dann hier in diesem Fall nur die jeweiligen module-configs auslesen und hat alle actions
welche in diesem modul vorkommen.

Wenn du dir mal die Clansuite_ACL aus dem Model anschaust, wirst du sehen,
das die actions in der resources-tabelle eingetragen sind und in der klasse ausgelesen werden.
Das ist also kein starres Model, sondern einfach nur der vereinfachheithalber fix eingegeben.
Ob diese nun wie von mir zu testzwecken alle gleich benannt sind, oder ob hier nun der action_name
steht ist bedeutungslos.
Ich habe das nur einfach nur mal zu darstellungszwecken schnell hingeklatscht, damit man visuell
ein Ablauf nachvollziehen kann. Wie sagt man so Schön: Bilder sprechen mehr als 1000 Worte 

Wie gesagt das ganze Model muss sich entwickeln und da die Rechteverwaltung ein elementarer
bestandteil des gesamten ist, kann man sich hier nicht genug auslassen und muss verschiedene
variationen antesten.

Es macht noch keinen Sinn das Model ins svn zu stellen, da mit diesem Model auch noch Tabellen
geändert werden, die vlt. nach einem anderen Model gar nicht geändert werden dürfen.

Wir sollten erstmal die Basis des Rechtesystems erarbeiten!

Gut wäre auch, wenn die anderen developer auch mal drüber schauen und ihre meinung dazu
äussern würden. Jeder hat ja so seine Erfahrungen und Vorstellungen.

Wie du sicherlich schon mehrfach bemerkt hast, erschrecken mich persönlich einfach die vielen
relationen. Ein Blick in die DB und man wird erschlagen von den relationen 

gruss
paul

[paulbr]

Hier mal ein kleiner Testreport

Im Modulemanager wird das Modul geprüft auf enabled/disabled.
Hierzu wird eine moduleregistry verwendet welche die module aus einer map liest.
Die Map wird nicht erstellt, weshalb alle Module disabled sind.
Ich umging das erstmal indem ich active = true in die info mit ablegte.

Zum Aufbau und Testen des Rechtesystems, ob es überhaupt so wie ich es mir
gedacht habe funktioniert, habe ich bei mir mal folgende Änderung vorgenommen.

Eine neue Funktion im Modulemanager action_admin_installallmodulefirsttime() regelt
die für die erstbenutzung Notwendigen Installationen der Module und Permissions.
Aufrufbar durch:
http://clansuite-dev.com/index.php?mod=modulemanager&sub=admin&action=installallmodulefirsttime

-------------------------
Beispiel-Modul: About
File: about.info.php
-------------------------
;----------------------------------------
; about_info
;----------------------------------------
[about_info]
author="Jens-André Koch"
license="GPLv2 or any later"
link="http://www.clansuite.com"
name = about
description =
dependencies =
package = Development
section =
active = true

;----------------------------------------
; about_package
;----------------------------------------
[about_package]
version = 0.2-0.x-dev
require_clansuite_version = 0.2
project = index
datestamp =
uniqueid =

;----------------------------------------
; about_widgets
;----------------------------------------
[about_widgets]

;----------------------------------------
; about_acl
;----------------------------------------
[about_acl]
action_show = 'all'
action_admin_show = 'r|a'
action_admin_edit_info = 'r|a'
action_admin_edit_menu = 'r|a'

Die Permissions sind:
root(r), admin(a), member(m), guest(g), bot(b)
Wenn alle das recht haben sollen reicht die Angabe: 'all'.
Wenn nur bestimmte Gruppen das recht haben sollen, dann die kürzel angeben, trennung durch |.
Die Reihenfolge der Eingabe für die Permission spielt keine Rolle.

Im Modulemanager werden in einer action funktion nun alle Moduleinfos gelesen, die Module
in die cs_module eingetragen, die actions der einzelnen Modulen in die cs_acl_resource und die
Permissionmatrix Gruppe<->Action in die cs_acl_rules.

Alle Permissions wurden korrekt auf die Erlaubte Gruppe und die in der info angegebenen actions
zugeordnet und in der Db gespeichert.

Durch Aufruf der Clansuite_ACL::getModulePermission('about') wurde das permission als Array
korrekt zurückgegeben.
Nun kann jede action mittels action name auf access geprüft und ggfs falls nicht vorhanden
umgeleitet werden.

Eintrag in cs_modules von allen Modulen, Permissions getestet nur an dem Modul About.
Nächster Schritt ist, das ich alle infos der einzelnen Modulen einmal um die obigen änderungen
erweitere um das komplett zu testen.

gruss
paul

[paulbr]

Die Rechte hab ich in die modules.config.php verschoben.
Beispiel: about.config.php
Der Grund, warum ich denke das die Rechte überhaupt in die moduleconfiguration sollten ist:
1. Bei der Moduleinstallation über den Modulemanager kann so für jedes Modul
    bereits default Rechte vorgegeben werden.
2. Es kann zu jederzeit ein Resett der Rechte für das jeweilige Modul stattfinden, ohne
   die default werte in einer extra Tabelle ablegen zu müssen.

Neuer Gedanke
Das Ziel ist es, eine möglichst umfassende, aber auch resourcen sparende lösung zu finden.
An dem Vorherigen beispiel gefiel mir nicht, das mehrere relativ grosse Arrays als cache
dienten. PHP hat hier zum einen auch seine Grenzen und zum anderen lässt die Ausführungszeit
und schnelle Verfügbarkeit an jeder Stelle innerhalb der Clansuite noch zu Wünschen übrig.

Zur Zeit experimentiere ich an folgender Idee:
Rechteverwaltung/Administration/Install wie im Vorposting.
Die Rechte welcher der User hat, werden in der user.core.php ausgelesen

Kleines Beispiel Rechte-Array an User Gast

$rights = array(
  'about' => array(
                    'action_show' => 1
                ),
  'news' => array(
                     'action_show' => 1,
                     'action_showone' => 0,
                     'action_getfeed' => 0,
                     'action_archive' => 0,
                     'action_fullarchive' => 0,
                     'action_admin_show' => 0,
                     'action_admin_create' => 0,
                     'action_admin_edit' => 0,
                     'action_admin_update' => 0,
                     'action_admin_delete' => 0,
                     'action_admin_settings' => 0,
                     'action_admin_settings_update' => 0
                )
);

Das Array wird nun serialisiert, base64 encodet und gz komprimiert, danach in die Session abgelegt.
So sind alle Rechte welche der User hat (Gruppe-/Userrechte) in dieser Tabelle vorhanden.
Die Rechte sind nun überall abgreifbar ohne nochmals an irgendeiner Stelle die Datenbank
beanspruchen zu müssen.

In der Session würde nun im Parameter 'rights' folgendes stehen:
"eNp1jkEOgyAQRe_CCQqxqR0O01AZlYRCI2NdGO5edSGFlO17_2VGgYA1wBWYevqZmFTAd8D5Rjoy3j3C6BcmDXAZAzTAHC7h2
InqcMNNhr3D3VxccjMg9Yj6j1FTN5pPatrT9LO1pb2lTr9MeuSQ90J2Eyqqt6gNVdv5rX_bUmu0mLTg5VtIZNwQzkFbGWR3YvwC9ZuNzg,,"

Jetzt könnte man noch, um möglichst wenig Resourcen zu verbrauchen, anstatt aller Rechte auch nur die erlaubten Rechte
in das Array zusammenfassen. Eine Prüfung in den einzelnen Modulen/Menüs/Routing würde dann auf Vorhandensein reichen.

An obigen Beispiel wäre das:

$rights = array(
  'about' => array(
                    'action_show' => 1
                ),
  'news' => array(
                     'action_show' => 1
                )
);

und der String in der Session:
"eNpLtDKyqi62MrVSSkzKLy1Rsk60MgQJGBoCRZJLMvPz4osz8suVrDOtDK1ri61MrJTyUsuLCairBVwwtb8b8w,,"

Die Array's groups sowie rights benötigt man in der session nicht.
Entweder ist der User: Bot, Gast, Member, Admin oder Rootadmin.
Ein Member kann auch einzelne Adminrechte über die Userrechte erhalten, welche dann
ebenfalls in seinem Rechtearray abgelegt werden.
Dafür wird: group (integer), role_id (integer) und rights (string) benötigt.

Was denkt Ihr zu dieser Idee?
Wäre dies ein Ansatz auf den man setzen kann?

Die Clansuite soll neue Wege gehn, bessere Wege gehn, nicht weil viele anderen Etablierten
Systeme dies anders machen, muss es auch besser sein 

Ich denke hier sollten wirklich alle Interessierten ob developer oder nicht, mal Ihre Meinung/Vorschlag äussern.
Im Endeffekt wird ja jeder, der sich hier Registriert, den Gedanken haben, die Clansuite irgendwann mal für sich einsetzen zu wollen.
Das Rechtesystem ist etwas Elementares, welches gut durchdacht und Flexibel sein muss.

@jens:
Es macht keinen Sinn das jetzt ins SVN zu legen, erst muss mal klar sein, wie man das Rechtesystem
nun machen will. Es wäre zu Umständlich alles wieder rauszuziehn um es dann anders zu machen.

Soviele Leute lesen das Forum, ich denke da werden doch einige dabei sein, welche die Entwicklung der Clansuite
mit Interesse verfolgen und bestrebt sind das die CS vollkommen wird 


gruss
paul

[paulbr]

Das Rechtesystem wird nun wie fogt integriert:

1.) Default Action Rechte
    default Rechte werden in der module.config.php des jeweiligen
    Modules definiert.
    e.g.:
    [properties_acl]
    action_show = 'all'
    action_admin_show = 'r|a'
    action_admin_edit_info = 'r|a'
    action_admin_edit_menu = 'r|a'


2.) Installation Modul und Gruppenrechte
    Mittels des Moduleinstallers werden die Module in die cs_module eingetragen.
    Die Rechte werden anhand der Permission und den definierten Actions vorerst aus der
    modules.config.php automatisch in die ACL-Tabellen eingetragen.
    Zu einem späteren Zeitpunkt wird diese evtl. in die package.xml verlagert werden.
    Hindergrund: So kann zu jederzeit ein Reset der Rechte auf die Defaultwerte erfolgen.

3.) Manuelles Überarbeiten der Gruppenrechte
    Manuell können alle Actions der jeweiligen Module über den Modulemanager aufgerufen
    und überarbeitet werden.
    Wird ein Recht gegeben, wird es in den Rules eingetragen.
    Wird ein Recht entfernt, wird es aus den Rules gelöscht.

4.) Manuelle Vergabe von Userrechten
    Wenn ein User zusätzlich zu seinem Gruppenrecht weitere Rechte bekommen soll,
    kann man dies über den Usermanager für jeden einzelnen User selektiv erstellen.

5.) Manuelle Vergabe von Dateirechten
    --- nicht Implementiert, da zur zeit nicht benötigt ---
    Verwaltung der Gruppen-Dateirechte über Filemanager (Downloads, Bilder...).
    Formular-Erweiterung des Usermanager auf verwaltung von Dateirechten für einzelne User.

6.) Bereitstellungsprozess
    Bei öffnen der Clansuite wird für jeden User eine Session angelegt.
    Die Gruppenrechte (Gast) werden hierbei ausgelesen und mittels
    Serialisierung, Base64 kodierung und kompression in der Session abgelegt.
    Nach einem Login werden zu den Gruppenrechten des Users auch die, wenn vorhanden,
    Speziellen Userrechte ausgelesen. Speicherung wie vor in der Session.
    Gespeichert werden generell nur Rechte, welche auch vorhanden sind.

6.) Rechteprüfung
    Mittels einer Funktion z.b. 'checkPermission' können nun Global die jeweiligen Rechte geprüft werden.
    Da der Bereitstellungsprozess der Rechteerstellung bereits vor dem Frontcontroller stattfindet, sind
    die Rechte jederzeit und überall abrufbar.
    Im Menü kann jedes Modul auf action_show(öffentlich) / admin_action_show(administration) jederzeit geprüft
    und entsprechend der Link ausgegeben oder gesperrt werden.

Vorteil bei diesem Rechtesystem ist:
  - kein grosser Aufwand mit der Rechtevergabe, da die Gruppen defaultrechte automatisch gesetzt werden.
  - man benötigt lediglich 1 Funktion um von überall die Rechte Abprüfen zu können.

Im Normalfall bedarf das Rechtesystem keine langwierige Administration, da die Defaultrechte bereits
Gruppenorientiert in den einzelnen Modulen enthalten sind und bei der Installation gesetzt werden.

Tiefgreifende Systemänderungen sind hier nicht nötig.
 - neues Modul: acl (Add/Edit/Delete der Rechte im Adminbereich)
 - neue Klasse: Clansuite_ACL
 - Neue DB-Tabellen:
    + cs_acl_role       (Rechtegruppen)
    + cs_acl_actions  (Module Actions)
    + cs_acl_rules      (Rechtetabelle gruppe <-> actions)
    + cs_acl_urules    (Rechtetabelle user <-> actions)

    @todo
    + cs_acl_frules     (Rechtetabelle gruppe <-> dateien/bilder)
    + cs_acl_ufrules    (Rechtetabelle user <-> dateien/bilder)

 - user.core.php:
    + einfügen der role_id in die User-Session
    + einfügen der Rechte in die Session

Im Anhang ist ein Blockschema des ACL um sich das Visuell vorstellen zu können.


gruss
paul

[Jens-A. Koch]

7. Rechteprüfung - Smarty Viewhelper check_permission

Ich hab einen Smarty Viewhelper check_permission eingefügt.
Damit ist es möglich in Smarty Templates eine Rechteprüfung durchzuführen.
Es ist eine einfache Parameterweiterleitung an Clansuite_ACL::checkPermission().
Erforderliches Parameterformat ist "modulname.actionname."

Beispiel:

{if true == {check_permission name="index.action_show"}}
   <font color=blue>Der User hat das Recht auf: index.action_show</font>
{else}
   <font color=red>Der User hat <u>kein</u> Recht auf: index.action_show</font>
{/if}

[paulbr]

Super

{if true == {check_permission name="index.action_show"}}

genauso hab ich es mir vorgestellt.

So kann die Toolbox mit Developer Tools bestückt werden, mit
{if true == {check_permission name="toolbox.widget_toolbox"}}
kann man die Toolbox für die Developer anzeigen, für die Besucher und normalen Member ausschalten.

Muss dem CssBuilder nur noch das Theme mit übergeben, so kann dieser unabhängig agieren, ohne
in diesem erst einstellungen machen zu müssen.
Das gleiche für den CssEditor.
Hier würde dann auch ein TemplateEditor bzgl. dem aktuellen template Sinn machen.

Der Designer kann dann die aktuelle Seite direkt über die Editoren ändern und anschauen.

So langsam nimmt das ganze eine Form an die begeistert 

gruss
paul