Spring: Werte speichern über Requests hinwege ohne DB

[Schuriko]

Ich entwickle gerade eine datenbankbasierte Web-Anwendung. Hierbei möchte ich einen Wert über mehrere Requests hinweg für ein bestimmten Anwender festlegen. D.h. der Wert des einen Anwenders kann von dem Wert eines anderen Anwenders unterschiedlich sein. Ich bin am Überlegen diesen Wert in eine Session zu speichern, wie ich es von PHP her kenne. Gibt es in Java, da die Anwendung, ja nicht immer wieder neu ausgeführt wird, einen alternativen - evtl. bessern - Weg?

 

[Thallius]

Ja du speicherst ihn in der Datenbank. Was hält Dich denn davon ab?

 

[sascha-sphw]

Du könntest es auch im Web Storage abspeichern, dann brauchst Du weder DB noch Sessions.

https://wiki.selfhtml.org/wiki/JavaScript/Web_Storage

Hängt aber stark davon ab was genau Du speichern möchtest.

 

[Schuriko]

Ja du speicherst ihn in der Datenbank. Was hält Dich denn davon ab?

Weil es Werte sind die nicht in die Datenbank gehören. z.B. (Ja ich weis etwas abwegig) wenn ich den angemeldeten Benutzer mir merken möchte.

 

[mrBrown]

Kannst das durchaus in der Session speichern (die allerdings auch in der DB stehen kann...). Eine andere Möglichkeit wäre zB ein Key-Value-Store wie Redis oder vergleichbares.

Weil es Werte sind die nicht in die Datenbank gehören. z.B. (Ja ich weis etwas abwegig) wenn ich den angemeldeten Benutzer mir merken möchte.

Schlechtes Beispiel, weil du dir den nicht selbst merken muss und Spring den je nach Config in einer DB speichert

Um was für Daten geht es denn wirklich?

 

[Schuriko]

Du könntest es auch im Web Storage abspeichern, dann brauchst Du weder DB noch Sessions.

https://wiki.selfhtml.org/wiki/JavaScript/Web_Storage

Hängt aber stark davon ab was genau Du speichern möchtest.

Wie kann ich den Serverseitig unter Java damit arbeiten?

 

[Schuriko]

Kannst das durchaus in der Session speichern (die allerdings auch in der DB stehen kann...). Eine andere Möglichkeit wäre zB ein Key-Value-Store wie Redis oder vergleichbares.


Schlechtes Beispiel, weil du dir den nicht selbst merken muss und Spring den je nach Config in einer DB speichert

Um was für Daten geht es denn wirklich?

Ja, deshalb meinte ich auch vielleicht ein etwas abwegig.

Es geht um verschiedene Daten, um ein konkretes Beispiel zum Veranschaulichen herauszunehmen - die gerad vom Benutzer des Systems ausgewählte Sprache

 

[Thallius]

Gerade die sollte in der Datenbank stehen. Oder hast du lust auf jedem Rechner von dem aus du die Software benutzt erst wieder die Sprache einzustellen?

Ich habe früher auch viel mit Cookies (Was großartig anderes ist WebStore ja auch nicht) und Sessions gearbeitet. Mitlerweile geht bei mir alles in die DB. Nur dadurch ist gewährleistet, dass der User, egal von wo aus er sich einloggt, immer das gleiche Bild bekommt.

Claus

 

[mrBrown]

Wie kann ich den Serverseitig unter Java damit arbeiten?

Gar nicht, das ist rein Clientseitig im Browser.

 

[Schuriko]

Gerade die sollte in der Datenbank stehen. Oder hast du lust auf jedem Rechner von dem aus du die Software benutzt erst wieder die Sprache einzustellen?

Nein es gibt ja auch eine Datenkbank "languages" mit den gespeicherten, zur Verfügung stehenden Sprachen. Die Tabelle beinhaltet auch eine Feld "default" für einen Standardwert.

ABER:
Angenommen man hat einen Shop. Dieser Shop stellt zum Einkauf n Artikel dar. Der Shop soll international sein sagen wir mal Deutsch, Englisch, Japanisch und Finnisch. Deshalb sind alle Artikel auf diese Sprachen beschrieben.

Jetzt kommt ein potenzieller Käufer auf diesen Shop und schaut sich ein paar Artikel an. Dieser stellt den Shop auf seine Sprache ein, die er versteht. Jetzt will der Käufer natürlich nicht bei jedem anderen Seitenaufruf die Sprache neu einstellen müssen. Also muss für diese Session die Sprache, die der Käufer eingestellt hat, vermerkt werden. Dieses muss das System natürlich wissen, damit er beim Anfordern eines Artikels, diesen in der jeweils ausgewählten Sprache anfordert.


Bisher habe ich es immer über Sessions gelöst. Mein Frage war nun gibt es andere Programmiermöglichkeiten? Wie würdet ihr das lösen. Ich versuche gerad herauszufinden ob man nicht etwas wie Bean Scopes dafür verwenden kann.

Das beschriebene Beispiel mag ich persönlich nicht in der Datenbank vorhalten, aus dem ganz einfachen Grund weil, wenn man es nicht technisch gelöst hat, das System nie weis ob der Benutzer nicht evtl. den Browser geschlossen hat. D.h. mit anderen Worten irgendwann hat man eine Datentabelle mit n Datenzeilen die man nicht mehr benötigt.

Bitte kommt mir jetzt aber nicht mit der (persönlichen Meinung) laienhafte Aussage: "Das ist doch egal ich habe genügend Platz". Weil dieses bestimmt nicht Ressource schonend ist.

Ich habe früher auch viel mit Cookies (Was großartig anderes ist WebStore ja auch nicht) und Sessions gearbeitet. Mitlerweile geht bei mir alles in die DB. Nur dadurch ist gewährleistet, dass der User, egal von wo aus er sich einloggt, immer das gleiche Bild bekommt.

Claus

Deine Annahme geht davon aus das sich der Benutzer einloggen muss - sprich eine eindeutige Identifizierung - um die von diesem Benutzer zuletzt eingestellte Sprache zu ermitteln. Aber in dem beschriebenen Beispiel loggt sich der Benutzer nicht ein. Sprich man kann ihn auf diesen Weg nicht eindeutig identifizieren.

 

[mrBrown]

Bisher habe ich es immer über Sessions gelöst. Mein Frage war nun gibt es andere Programmiermöglichkeiten? Wie würdet ihr das lösen. Ich versuche gerad herauszufinden ob man nicht etwas wie Bean Scopes dafür verwenden kann.

Das nutzt letztendlich alles irgendwie die Session.

Das beschriebene Beispiel mag ich persönlich nicht in der Datenbank vorhalten, aus dem ganz einfachen Grund weil, wenn man es nicht technisch gelöst hat, das System nie weis ob der Benutzer nicht evtl. den Browser geschlossen hat.

Angenommen Nutzer stellt seine Sprache ein, schließt den Browser, und öffnet die Seite direkt neu - soll dann die Sprachauswahl weg sein?

 

[sascha-sphw]

Deine Annahme geht davon aus das sich der Benutzer einloggen muss - sprich eine eindeutige Identifizierung - um die von diesem Benutzer zuletzt eingestellte Sprache zu ermitteln. Aber in dem beschriebenen Beispiel loggt sich der Benutzer nicht ein. Sprich man kann ihn auf diesen Weg nicht eindeutig identifizieren.

Was stört Dich denn, für diesen speziellen use case, an Cookies; session_lang und gut. Wo meinst Du wird die SessionID beim Client gespeichert während einer laufenden Session?
Und ja, die kannst Du auch Serverseitig abfragen, die werden bei jedem Request vom Client mit zum Server geschickt.

 

[Schuriko]

Das nutzt letztendlich alles irgendwie die Session.


Angenommen Nutzer stellt seine Sprache ein, schließt den Browser, und öffnet die Seite direkt neu - soll dann die Sprachauswahl weg sein?

Wie identifizierst du in diesem Fall den Nutzer?

 

[mrBrown]

Wie identifizierst du in diesem Fall den Nutzer?

Na das macht Spring. Wenn du den irgendwo brauchst, lass ihn dir einfach vom Container geben, zB im Controller als Methodenparameter.

EDIT: missverstanden, einfach über einen Cookie, der auch Browser-Neustarts übersteht wenn nötig.

 

[Schuriko]

Wo meinst Du wird die SessionID beim Client gespeichert während einer laufenden Session?

Session sind keine Cookies.

IDUs werden bei Sessions serverseitig gespeichert, daher sind sie sicherer. Der Ablauf von Sessions kann nicht festgelegt werden, sie verfällt wenn der Browser geschlossen wird.

IDUs werden bei Cookies clientseitig gespeichert, dadurch unsischerer, weil sie durch Hack-Angriffe manipuliert werden könnten.
Die Verfallszeit von Cookies kann festgelegt werden.

 

[Schuriko]

Na das macht Spring. Wenn du den irgendwo brauchst, lass ihn dir einfach vom Container geben, zB im Controller als Methodenparameter.

EDIT: missverstanden, einfach über einen Cookie, der auch Browser-Neustarts übersteht wenn nötig.

Hab deine Antwort bzgl. meiner Frage nur halbwegs verstanden. Kannst du mir ein Code-Beispiel nenne zum Verständnis?

 

[mrBrown]

Du musst immer etwas Client-Seitig speichern, da du sonst die Session Server-Seitig nicht zuordnen kannst. Nahezu immer ist das eine SessionID in einem Cookie. Ob der Client den manipuliert ist egal, im schlimmstem Fall ist er ausgeloggt (wofür man keinen Cookie manipulieren muss.)

Ob der Browser noch offen ist, kannst du Server-Seitig überhaupt nicht mitbekommen (außer, du setzt auf Longpolling oder Websockets oä, ist aber unüblich).

Was sollen IDUs sein?

 

[sascha-sphw]

Session sind keine Cookies.

IDUs werden bei Sessions serverseitig gespeichert, daher sind sie sicherer. Der Ablauf von Sessions kann nicht festgelegt werden, sie verfällt wenn der Browser geschlossen wird.

IDUs werden bei Cookies clientseitig gespeichert, dadurch unsischerer, weil sie durch Hack-Angriffe manipuliert werden könnten.
Die Verfallszeit von Cookies kann festgelegt werden.

Siehe @mrBrown's post. Aber ließ Dich doch bitte nochmal genauer in die Themaik ein, Du hast da ganz kleine Lückchen.

Sicherheit ist prinzipiell Chef- (Server-) Sache, egal was Dir der Client unterjubelt.

 

[Schuriko]

@mrBrown IDUs sind Identifiy Units
@mrBrown und @sascha-sphw Ihr scheint hier ein paar kleine technischen Irrtümern unterlegen zu sein. Ich zettiere hier aus dem als ersten Eintrag unter Google Suche: "Session vs Cookie" -> "The Difference Between Session und Cookies in PHP" ... ja, ja ich weis es ist PHP, ich denke aber mal Java wird es nicht anders machen. Sollte ich mich Irren, bitte entsprechende Quelle angeben.

 

[mrBrown]

Das stimmt auch alles, wiederspricht allerdings unseren Aussagen überhaupt nicht.

Die Session selbst ist Server-Seitig gespeichert. Eine SessionID, mit der der Client bzw. ein Request, einer Session zugeordnet wird, ist Client-Seitig gespeichert.


Oh, und auch Sessions können natürlich verfallen, es ist zB in Java völlig üblich, dass die nach X Minuten Inaktivität geschlossen wird (Inaktivität ist eben auch der einzige Weg, einen geschlossenen Browser frstzustellen)

 

[Schuriko]

irgendetwas anders habe ich ja auch nie behauptet , als das was z.B. unter ""The Difference Between Session und Cookies in PHP" steht.

 

[sascha-sphw]

@mrBrown IDUs sind Identifiy Units
@mrBrown und @sascha-sphw Ihr scheint hier ein paar kleine technischen Irrtümern unterlegen zu sein. Ich zettiere hier aus dem als ersten Eintrag unter Google Suche: "Session vs Cookie" -> "The Difference Between Session und Cookies in PHP" ... ja, ja ich weis es ist PHP, ich denke aber mal Java wird es nicht anders machen. Sollte ich mich Irren, bitte entsprechende Quelle angeben.

Frag Dich doch mal, woher der Server weiß, welche Session er laden muss.
Daher sagte ich in einem anderen Post auch.

Hängt aber stark davon ab was genau Du speichern möchtest.

Bei der temporär eingestellten Sprache würde ich aber sagen, dass die ruhig in einem Cookie verstaut werden kann. Gerade weil Du gesagt hast, dass Du dafür keine Datenbank bemühen möchtest. Du könntest Dich aber bei der Gelegenheit auch mal fragen wie der Server die Daten die zu einer Session gehören verwaltet.

 

[Schuriko]

Aber trotzdem Danke @All

 

[mrBrown]

irgendetwas anders habe ich ja auch nie behauptet , als das was z.B. unter ""The Difference Between Session und Cookies in PHP" steht.

Na und wir unterlagen keinen technischen Irrtümern

 

[Schuriko]

Na und wir unterlagen keinen technischen Irrtümern

Dann sind wir uns ja einig