nicht angemeldet
Hi!
Ja klar, ich möchte die Benutzerdaten auch so zeitig wie möglich erfahren um sie z.b. auch den Modulen zur Verfügung zu stellen.
So zeitig wie möglich ist nicht notwendig. So zeitig wie nötig wäre auch ausreichend. Dann
Trotzdem muss ich doch aber eine Gegenprüfung bzgl. der Benutzergruppen/-rechte durchführen. Oder nicht? Ansonsten könnte der Client seinem Cookie doch z.B. einfach eine Gruppe hinzufügen. Das hat dann nichtmal was mit Session-Diebstahl zu tun. Oder versteh ich da was falsch?
Ja. Öffne eine Session, schreib ein paar Werte hinein. Mach einen zweiten Request, schau nach, ob die Werte noch da sind. Schau dir nun im Browser die Cookies an. Was siehst du? Nur die Session-ID. Wenn man nicht nur die Session-ID sondern auch alle Daten ständig zwischen Client und Server hin- und hersendete, bräuchte man den Session-Mechanismus nicht, das ginge mit einfachem GET/POST/COOKIE, wobei GET und Cookies den Nachteil der De-Facto-Größenbeschränkung haben.
Session-Daten liegen immer auf dem Server. Aber auch da kannst du nicht die Hände in den Schoß legen sondern solltest dich auch dort mit den möglichen Risiken vertraut machen. Beispielsweise wenn alle Anwendungen nur ein gemeinsames Session-Verzeichnis nutzen, dann können sich die Garbage-Collectors der Anwendungen gegenseitig die Session-Dateien löschen, wenn diese (GCs) unterschiedliche Ablaufzeiten eingestellt haben. Ein separates Verzeichnis für Session-Daten verhindert dies. Dies nutzen zu können setzt aber voraus, dass einem der Hoster Platz außerhalb des DocumentRoots zur Verfügung stellt oder sich die DocumentRoots in Unterverzeichnisse des Kundenverzeichnisses legen lassen und man dann "daneben" Platz hat.
Lo!