nicht angemeldet
Hallo Michi,
Das nachladen, bzw. neu selektieren von zusätzlichen Details zum Benutzer wollte ich mir ersparen, damit ich weniger Anfragen zur DB stelle. Dafür hätte ich dann, wenn ich beim ersten Selektieren viel hole und nen dicken Objekt habe und den von Seite zu Seite herumschleife.
Diese Objekte werden ja auch wieder serialisiert oder in einer Datenbank abgelegt (jedenfalls vermute ich das, der Servlet-Container kann sie natürlich auch einfach im Speicher halten, bei vielen Sessions ist das aber sicher keine gute Idee). Daher kann es durchaus schlechter oder genau so schlecht sein, die Daten in der Session mit zu schleppen, als sie bei Bedarf erneut aus der Datenbank zu holen.
So lang es dabei nur um ein paar Eigenschaften geht, die in einer Tabelle stehen, würde ich mir da aber nicht so viele Gedanken machen.
Was ich zwecks Sicherheit nachfragen wollte. Ich habe gehört, dass man von Session auch die darin gespeicherten Objekte auslesen könnte, falls dies von einem anderen ergattert ist. Geht das problemlos?
Zum Browser wird ja nur die SessionID übertragen. Um eine Session zu übernehmen, muss ein Angreifer diese SessionID herausfinden. Wenn er sie hat, kann er alles tun, was der "Besitzer" der Session tun könnte. Die in der Session gespeicherten Daten liegen aber nur auf dem Server, an diese kommt er also nicht direkt ran. Natürlich kann er Daten über die Weboberfläche einsehen, die ein Benutzer selbst einsehen könnte.
Wollte nämlich evtl. die DB-Verbindung evtl. in die Session speichern, wenn ein User eine Seite aufruft.
Das ist aus mehreren Gründen keine gute Idee.
- Session-Objekte müssen serialisierbar sein, Objekte, die irgend welche externen Resourcen repräsentieren, sind das typischerweise nicht.
- Man will nicht für jede Session eine Datenbankverbindung aufmachen, da das sehr viele werden können. Man macht also nur so viele Datenbankverbindungen auf, wie man gleichzeitig benötigt.
- Datenbankverbindungen werden typischerweise in einem Pool vorgehalten, sodass sie für beliebige Anfragen wiederverwendet werden können. Hibernate verwaltet Datenbankverbindungen auch so. Es ist normalerweise nicht nötig, für eine Session eine eigene Datenbankverbindung zu verwenden.
Der Lehrbuch-gerechte Ansatz wäre wohl, in der Session entweder die Benutzer-ID oder ein Benutzer-Objekt zu speichern und sich um das nachladen evtl. notwendiger Daten keine Gedanken zu machen, sondern dies Hybernate zu überlassen.
Man würde also für jeden Request das Benutzer-Objekt aus der Session laden, sich eine DB-Verbindung aus dem Pool holen und eine Transaktion starten, das Objekt wieder an die Transaktion binden (das muss man explizit tun, wenn man Datenobjekte über mehrere Transaktionen hinweg verwendet.)
Anschließend kann man mit dem Objekt weiterarbeiten, ohne sich um irgend etwas zu kümmern.
Grüße
Daniel