nicht angemeldet
Hallo Christian!
- habe 4 verschidene Benutzegruppen die jeweils einen eigenen Login-Bereich haben müssen, mit verschiedenen Funktionalitäten...
Löse das über eine Rechteverwaltung. Du kennst "Access Control Lists"? (Beispiel: Rechteverwaltung unter Win NT, 2000, XP und .NET Server)
Was heißt kenne? Ich habe mich schonmal als User unter Win2K oder Linux eingewählt, sowas in der Art hätte ich auch gerne, nur habe ich zur Zeit das Problem, das sich mindestens 5 wirklich umfassende neue Gebiete alle gleichzeitig in einem Projekt das erste mal ausprobiere, bzw. versuche zu verstehen, das wird mir langsam alles zu kompliziert, ich blicke jetzt schon kaum noch durch, eben weil das so viele unbekannte Techniken sind, noch sowas kann ich zur Zeit glaube ich nicht mehr verkraften denn die Entwicklung wird auch immer langsamer dadurch.
Wenn Du Access Control Lists implementierst, und zwar Rechte auf _jedes_ Objekt, also Menüeinträge, Module, etc. - dann kannst Du das ganze nur mit einem Login lösen und hast das ganze enorm vereinfacht.
Ich mache ja ein Login. ich habe 2 Tabellen:
1. Tabelle: "User" mit den Spalten "UserID","GroupID", "Username", "Password", "Status"(damit kann ich einen User sperren)
2. Tabelle: "Groups" mit den Spalten "GroupID", "GroupName", "Status"(damit kann ich eine Gruppe sperren)
Ich prüfe nach erfolgreichem Login in welcher Gruppe der User ist, also z.B. Group-Name "lieferanten". Damit habeich die Angabe welches Script er verwenden kann. Es ist nicht wie bei Windows wo alle User im Prinzip zu 98% das gleiche Programm haben nur mit ein paar individuell unterschiedlichen Einstellungen und Rechten. Bei mir sind es grundverschiedene Menüs, mit genau gegensätzlichen Funktionen. Daher liegt es für mich nahe das z.B. Lieferanten alles eigene Scripte haben, was die Ausgabe und Interaktion angeht. Genauso eigene Templates und eigene Language-Files. Ich hatte daher erst gedacht, ich lege ein extra Verzeichnis für jeden Group-Name an, aber das wird dann kompliziert mit den Modulen. Wie gesagt sind meine Module eher Plugins, ich nenne sie nur so da ich persönlich den Begriff passender finde.
Ein Beispiel für ein "Modul" wäre wie gesagt der "Fragebogen-Generator". Das ist eine Erweiterung des Basis-Programms, und zwar um je 2 Webseiten bei 3 der 4 Benutzergruppen. Das hieße ich müßte in 3 ordner 6 Scritpe, Lang-Files und Templates verteilen. kann es nicht sein. Und je einen Unterordner pro Modul ist auch nicht viel besser. Alles was das Modul braucht muss in ein Verzeichnis, und so habe ich es auch gemacht. In dem Verzeichnis befinden sich jetzt alle Scripte, Templates und Lang-Files die ich jetzt in dem Beispiel Fragebogen-Generator brauche.
In dem Modul-Ordner liegt dann auch ein Script welches die Funktionen etc. enthält, die das Basis-scrtipt(index.php) braucht um z.B. die Menü-Struktur oder die Rechtevergabe zu regeln, wobei ich mir das bei letzterem nicht ganz vorstellen kann wie das funktionieren soll. Der eingeloggte "lieferant" kann innerhalb der Module nur auf Scripte mit "lieferant.{scriptname}.php" zugreifen. Wenn ich diese Benennung aber abschaffe, dann wird das ganze _sehr_ unübersichtlich, woher weiß ich jetzt hinterher für wen welche Scripte waren, wer auf was genau zugreift...
Womit Du Recht hast ist das ich nicht "lieferant" über die url mitschleppen muß, er muß sich eh jedesmal authentifizieren und so kann ich es auch ermitteln.
Wie würde denn so eiej Rechtevergae jetzt praktisch aussehen? Mein modul.setup.php Script enthält jetzt z.B. eine Klasse in der Methoden stehen aus denen sich das Basisscript Infos zur Navigationsleirste holen soll, genauso könnte da eine Methode für Rechtevergabe stehen.
Nur was genau sollte die machen? Sicher kein Problem, einfach sagen wer Zugriff hat und wer nicht, z.B. in dem die Methode einen Array zurückgibt mit
array("lieferanten => true, "admin" => false...);
Nur was mache ich dann im Basisscript mit der Information? Das wäre lediglich ein zusätzlicher Sicherheitsmechanismus, was ich aber eiugenbtlich schon durch die dynamisch zusammengesezten Namen habe.
Wenn Vom Browser ein HTTP Request kommt bekomme ich folgende Informationen:
Welcher User? => Group-Name
Modulename aus URL
Scriptname aus URL
ggfs. Parameter aus Umgebuingsvariablen
Dann setzt das Bsisscript an und formt nach Authentifizierung... wie beschrieben den include:
include(ROOTPATH.$modulname."/".$groupname.".".$scriptname.".php");
Dann wird das was im Script steht ausgeführt. Was sollen jetz noch die USer-Rechte?
_Vor_ dem Include werden noch alle modul.setup.php-Dateien geladen und entsprechend das Menü erzeugt, und von mir aus ein Array mit Benutzerrechten, aber was bringt das an dieser Stelle?
- Müssen Module unabhängig von der Basisvwersion hinzufügbar und entfernbar sein. Die Module können auf alle 4 Benutzergruppen-eigene Seiten Einfluß haben, ob jetzt Menüstruktur, extra Seiten/-Funktionalitäten, Datenbank-Tabellen...
Module sollte erst einmal unabhängig vom Menü sein. Du solltest in einer Menüverwaltung die Module manuell mit einem Menüpunkt verknüpfen können. (Genaugenommen speicherst Du dann einen Pfad zum Menüpunkt, der dann verlinkt wird)
Wieso? Alle notwendigen Module-setup-Dateien werden geladen, alle haben bestimmte Methoden aus denen sich dann das genamte Menü und die Nutzerrechte zusammensetzen, vollautomatisch. Warum nicht? Ich hatte damals CK so verstanden das ich das genau so machen soll.
und wenn ich es entferne verschinden die Funktionalitäten und Menüpunkte wieder. Sicher sinddas noch ein paar Kleinigkeiten die ich noch nicht im Detail geplant habe, aber ich denke das müßte ich so hinbekommen.
Schlechte Idee, siehe einen Absatz höher.
Aber gerade das will ich doch! Wo soll das Problem sein? Wennich 1000 Eisntellungen vornehmen muß, dann kann ich das in ein paar Monaten nicht mehr nachvollziehen, udn jemand anders überhaupt nicht, ich hatte nicht vor 250 Seiten Dokumentation zu schreiben ;-)
Vermutlich mache ich ein "add.module.fragebogengenerator.php" -Script, welches alle Einstelluneg vornimmt, und genauso "delete.module.fragebogengenerator.php" welches alles wieder entfernt.
Schlechte Idee. Im Prinzip sollte ein Modul (oder Untermodul oder wie Du es organisierst) eine Datei sein. Diese Datei musst Du hochladen. Dann steht das Modul in der Administration zur Verfügung. In der Administration kannst du das Modul dann einrichten. Wenn das Modul Tabellen braucht, dann hast Du noch 2 zusätzliche SQL-Scripte, die Du dann einspielen kannst - eines, um die erforderlichen Tabellen zu erstellen und eines, um sie wieder zu löschen. Diese solltest Du auch manuell einspielen. (evtl. über ein Administrationsinterface, aber immer noch manuell)
Hm. Hast Recht, mit so einem Admin-Menü wäre auch noch eine Möglichkeit. Aber sprechend wir besseer von plugins als von Modulen, ich habe das gefühl das wir unter "modul" nicht dasellbe verstehen.
Jedenfalls hast Du es mal wieder geschafft mich ordentlich zu verwirren und aufzuhalten ;-)
Aber genau das wollte ich ja, da ich weiß das es halt noch weit davon entfernt ist gut zu ein, also Danke für Deine Mühe und Geduld mit mit ;-)
Grüße
Andreas