nicht angemeldet
Perl: Sessions halten bei mehreren Servern (Serverfarm)
TSHi,
da ich in meinen Perl-Skripten ein Sessionmanagement nutzen will, dachte ich zuerst an das CGI-Modul. Jetzt ist es aber so, dass die Webseite innerhalb einer 'Serverfarm' läuft und es nicht klar ist, auf welchem der Server der jeweils nächste Request des Users ankommt.
Von daher muss ich mich selber um das Sessionmanagement kümmern, richtig? Aktuell denke ich daran, ein unique Id in einen Cookie zu schreiben und die dazugehörenden Daten in eine Datenbank zu schreiben.
Vom MySQL-Server gibt es nur einen, von daher sollte das dann problemlos gehen?!
Danke
-
Hallo Silvio,
abhängig von den Performance-Implikationen ist es ein denkbarer Weg, die Session in der Datenbank zu speichern, ja.
Gängige Praxis ist es allerdings heutzutage, die Session in einem Cookie zu speichern und den Inhalt zu verschlüsseln und zu signieren, so dass einerseits zwar der Client immer die Session-Daten liefert aber er andererseits auch nicht daran herum manipulieren kann. Die gängigen größeren Web-Frameworks handhaben das alle so.
LG,
CK-
Ah ok, vielen Dank.
Das kann ich mir mal anschauen, wäre aus Performancegründen sicher der bessere Weg.
-
Das kann ich mir mal anschauen, wäre aus Performancegründen sicher der bessere Weg.
Wenn das für Dich passt: super! Falls nicht, kann ich aus Erfahrung beitragen, dass eine Lösung mittels eines zentralen Memcache selbst bei recht großen Projekten / Nutzerzahlen sehr gut skaliert. Aber es hat natürlich auch seine Grenzen, klar.
-
Hallo Mitleser,
Wenn das für Dich passt: super! Falls nicht, kann ich aus Erfahrung beitragen, dass eine Lösung mittels eines zentralen Memcache selbst bei recht großen Projekten / Nutzerzahlen sehr gut skaliert. Aber es hat natürlich auch seine Grenzen, klar.
Ja, mit Memcached als Session-Store bei PHP-Projekten habe ich auch gute Erfahrungen gemacht.
LG,
CK
-
-
-
Gängige Praxis ist es allerdings heutzutage, die Session in einem Cookie zu speichern und den Inhalt zu verschlüsseln und zu signieren, so dass einerseits zwar der Client immer die Session-Daten liefert aber er andererseits auch nicht daran herum manipulieren kann. Die gängigen größeren Web-Frameworks handhaben das alle so.
Inwiefern löst das denn das Problem der Zuordnung? Oder willst Du auf Sticky Sessions hinaus?
-
Hallo Mitleser,
Gängige Praxis ist es allerdings heutzutage, die Session in einem Cookie zu speichern und den Inhalt zu verschlüsseln und zu signieren, so dass einerseits zwar der Client immer die Session-Daten liefert aber er andererseits auch nicht daran herum manipulieren kann. Die gängigen größeren Web-Frameworks handhaben das alle so.
Inwiefern löst das denn das Problem der Zuordnung?
Silvios Problem ist, dass das alte[tm] Session-Handling die Session-Daten in Dateien geschrieben hat, die dann bei einer Software, die auf mehrere Server verteilt ist, nicht auf allen Servern zugänglich ist. Das Problem gibt es bei dem Ansatz Session-Daten im Cookie nicht mehr: dort sind die Session-Daten im Cookie und werden vom Client bei jedem Request erneut an den Server gesendet. Der muss den Cookie nur noch entschlüsseln und die Signatur überprüfen, und schon sind alle Session-Daten verfügbar.
Oder willst Du auf Sticky Sessions hinaus?
Nein.
LG,
CK-
Hello,
Silvios Problem ist, dass das alte[tm] Session-Handling die Session-Daten in Dateien geschrieben hat, die dann bei einer Software, die auf mehrere Server verteilt ist, nicht auf allen Servern zugänglich ist. Das Problem gibt es bei dem Ansatz Session-Daten im Cookie nicht mehr: dort sind die Session-Daten im Cookie und werden vom Client bei jedem Request erneut an den Server gesendet. Der muss den Cookie nur noch entschlüsseln und die Signatur überprüfen, und schon sind alle Session-Daten verfügbar.
Da ist doch aber ein Denkfehler in der Zeitlinie, oder? Das System wäre extrem fehleranfällig!
Wie kommt denn der Client an die aktuellen Daten, wenn er noch einen Reqest absetzen konnte, der auf dem Server auch noch abgearbeitet wurde, aber die Response nicht mehr entgegen nehmen konnte? Die sind dann verloren!Und wenn ich in der Sessiondatei z. B. 2 MByte gesammelt habe, soll ich die dann immer hin und her pingen und pongen? Auch das wäre unsinnig.
Eine Datenbank ist sicherlich eine passende Uniq Location für derartige Daten. Zur Not muss man sie eben auch wieder aufteilen nach Nutzerkreisen. Und wer würde den Softweareersteller überhaupt daran hindern, die Sessiondaten alle zentral auf einem einzigen Netzwerkfileserver im LAN (intrerne Zone) zu halten, auch wenn die Verarbeitung auf unterschiedlichen Hosts stattfindet?
sshfs machts doch ganz einfach möglich!
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es
Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.
-
Hallo TS,
Da ist doch aber ein Denkfehler in der Zeitlinie, oder?
Nein.
Das System wäre extrem fehleranfällig!
Nö, funktioniert gut. Wie etwa hier im Forum zu sehen. Und es funktioniert so gut, dass es der best practice ist…
Wie kommt denn der Client an die aktuellen Daten, wenn er noch einen Reqest absetzen konnte, der auf dem Server auch noch abgearbeitet wurde, aber die Response nicht mehr entgegen nehmen konnte? Die sind dann verloren!
Ja ach! Wenn eine Antwort vom Server verloren geht, sind Daten verloren! Mach Sachen! 😉
Und wenn ich in der Sessiondatei z. B. 2 MByte gesammelt habe,
Then you're doing it wrong. Eine Session hat hier selbst bei den komplexesten Anwendungen, die ich entwickelt habe, nur ein paar Byte. REST to the rescue! 2MB State sollte niemand haben. Tatsächlich benötige ich die Session nur in Ausnahmefällen…
Eine Datenbank ist sicherlich eine passende Uniq Location für derartige Daten. Zur Not muss man sie eben auch wieder aufteilen nach Nutzerkreisen. Und wer würde den Softweareersteller überhaupt daran hindern, die Sessiondaten alle zentral auf einem einzigen Netzwerkfileserver im LAN (intrerne Zone) zu halten, auch wenn die Verarbeitung auf unterschiedlichen Hosts stattfindet?
sshfs machts doch ganz einfach möglich!
SSHFS ist so ziemlich die langsamste und fehleranfälligste Variante, die man sich einfallen lassen kann. Da sind selbst Session-Daten auf einem NFS-Share noch deutlich robuster…
Am besten aber nutzt man gar keine übers Netzwerk shared files, das hat wirklich eine Menge Pitfalls. Wenn ich nur ans file locking auf Files in einem Netzwerk-Share denke, bekomme ich schon graue Haare. Oder was machst du etwa, wenn der Server einfach mal weg ist? Netzwerk ist bei weitem nicht unfehlbar…
LG,
CK-
Hello,
Das System wäre extrem fehleranfällig!
Nö, funktioniert gut. Wie etwa hier im Forum zu sehen. Und es funktioniert so gut, dass es der best practice ist…
"Funktioniert gut" ist keine Aussage über die Zuverlässigkeit. Und dass Tausende von Leuten fehlerhafte Konzepte benutzen, macht die Konzepte nicht richtiger.
Wie kommt denn der Client an die aktuellen Daten, wenn er noch einen Reqest absetzen konnte, der auf dem Server auch noch abgearbeitet wurde, aber die Response nicht mehr entgegen nehmen konnte? Die sind dann verloren!
Ja ach! Wenn eine Antwort vom Server verloren geht, sind Daten verloren! Mach Sachen! 😉
Ich nehme jetzt einfach mal an, dass Du mir auf humorvolle Weise sagen wolltest, dass Dich das nicht weiter interessiert?
SSHFS ist so ziemlich die langsamste und fehleranfälligste Variante, die man sich einfallen lassen kann. Da sind selbst Session-Daten auf einem NFS-Share noch deutlich robuster…
Im abgesicherten LAN-Betrieb mag man gerne unverschlüsselte Techniken benutzen. Vielleicht gibt es auch noch andere Möglichkeiten, Ressourcen im LA-Netzwerk zu teilen, die ich hier jetzt gewiss nicht alle aufzähle.
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es
Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.
-
Tach!
Das System wäre extrem fehleranfällig!
Nö, funktioniert gut. Wie etwa hier im Forum zu sehen. Und es funktioniert so gut, dass es der best practice ist…
"Funktioniert gut" ist keine Aussage über die Zuverlässigkeit. Und dass Tausende von Leuten fehlerhafte Konzepte benutzen, macht die Konzepte nicht richtiger.
ASP.NET nutzt(e) dieses Konzept seit 2002. Es existiert also schon seit langem genug Erfahrung damit.
Ja ach! Wenn eine Antwort vom Server verloren geht, sind Daten verloren! Mach Sachen! 😉
Ich nehme jetzt einfach mal an, dass Du mir auf humorvolle Weise sagen wolltest, dass Dich das nicht weiter interessiert?
Es war wohl eher damit gemeint, dass man sowieso damit rechnen muss, dass mal was verloren gehen kann, und man generell geeignete Maßnahmen bei Verlust vorsehen muss. Auch ein Session-Cookie kann abhandenkommen. In jedem Fall muss also der Client dem Server Daten bereitstellen, damit das System ordnungsgemäß funktioniert. Ob das nur ein Cookie ist, oder ob es mehr Daten sind, spielt dann auch keine Rolle mehr.
dedlfix.
-
Hello,
ASP.NET nutzt(e) dieses Konzept seit 2002. Es existiert also schon seit langem genug Erfahrung damit.
Das ist kein Grund. Das kommt von Microsoft, soweit ich mich erinnere und dort wird bekanntlich nie etwas fertig entwickelt, bevor es verbreitet wird. ;-P
Ja ach! Wenn eine Antwort vom Server verloren geht, sind Daten verloren! Mach Sachen! 😉
Ich nehme jetzt einfach mal an, dass Du mir auf humorvolle Weise sagen wolltest, dass Dich das nicht weiter interessiert?
Es war wohl eher damit gemeint, dass man sowieso damit rechnen muss, dass mal was verloren gehen kann, und man generell geeignete Maßnahmen bei Verlust vorsehen muss. Auch ein Session-Cookie kann abhandenkommen. In jedem Fall muss also der Client dem Server Daten bereitstellen, damit das System ordnungsgemäß funktioniert. Ob das nur ein Cookie ist, oder ob es mehr Daten sind, spielt dann auch keine Rolle mehr.
Das ist nicht genau genug betrachtet. Es kommt immer darauf an, auch welcher Seite (Client oder Server) die relevanten Daten gehalten werden sollen. Diese Seite sollte auch immer den letzten Stand kennen (gespeichert haben). Da viele Daten im Webumfeld erst einmal transient sind, wäre es ein extremer Overhead, dies nicht mit den üblichen (datensicheren) Sessionkonzepten zu lösen. Spätetens beim Löschen der Sessiondatei ist das Problem mit dem Datenmüll beseitigt. Anderenfalls wird das Müllwegräumen extrem aufwändig.
Was nicht committed ist, muss noch nicht persistent gespeichert werden. Um da zu früh abgespeichete unfertige Ziwschenlösungen später wieder zu entfernen, muss man sonst zusätzliche Maßnahmen vorsehen. Das kostet Entwicklungszeit, Ressourcen und Performance.
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es
Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.
-
Hallo TS,
Das ist nicht genau genug betrachtet. Es kommt immer darauf an, auch welcher Seite (Client oder Server) die relevanten Daten gehalten werden sollen. Diese Seite sollte auch immer den letzten Stand kennen (gespeichert haben).
Wie ich bereits vorher schrieb: die Session ist kein Zwischenspeicher. Wichtige Daten solltest du dort nicht speichern. Dafür gibt es andere Technologien, die besser geeignet sind. Welche genau das sind, entscheiden die Umstände im Einzelfall.
LG,
CK -
Tach!
ASP.NET nutzt(e) dieses Konzept seit 2002. Es existiert also schon seit langem genug Erfahrung damit.
Das ist kein Grund. Das kommt von Microsoft, soweit ich mich erinnere und dort wird bekanntlich nie etwas fertig entwickelt, bevor es verbreitet wird. ;-P
ASP.NET ist wie .NET keine Microsoft-interne Geschichte. Das nutzen sehr viele Entwickler für ihren Projekte. Es ist also nicht nur so, dass nur Microsoft damit Erfahrung hat, sondern eine ganze Menge mehr.
Heutzutage wird man aber eher nicht mehr auf das herkömmliche ASP.NET setzen, aber nicht etwa weil die Speicherung des Viewstate sich nicht bewährt hätte, sondern weil es modernere Verfahren zur Anwendungsentwicklung gibt.
Es war wohl eher damit gemeint, dass man sowieso damit rechnen muss, dass mal was verloren gehen kann, und man generell geeignete Maßnahmen bei Verlust vorsehen muss. Auch ein Session-Cookie kann abhandenkommen. In jedem Fall muss also der Client dem Server Daten bereitstellen, damit das System ordnungsgemäß funktioniert. Ob das nur ein Cookie ist, oder ob es mehr Daten sind, spielt dann auch keine Rolle mehr.
Das ist nicht genau genug betrachtet. Es kommt immer darauf an, auch welcher Seite (Client oder Server) die relevanten Daten gehalten werden sollen.
Was nützt es mir als Client, der den Session-Cookie verloren hat, dass der Server meine relevanten Daten in einer Session-Datei liegen hat, wenn ich ohne den verdammten Cookie nicht drauf zugreifen kann? Beide Teile sind relevant, ohne den anderen Teil ist keiner etwas wert. Ob das Gewicht dabei auf der einen oder der anderen Seite liegt, hilft dabei nicht weiter.
Wenn Daten wichtig sind, sollten sie nicht in oder unter Verwendung von potentiell verlierbaren Elementen gespeichert weren.
dedlfix.
-
-
-
Hallo TS,
Das System wäre extrem fehleranfällig!
Nö, funktioniert gut. Wie etwa hier im Forum zu sehen. Und es funktioniert so gut, dass es der best practice ist…
"Funktioniert gut" ist keine Aussage über die Zuverlässigkeit.
Natürlich ist es das. Sonst hätte ich ja nicht „funktioniert gut“ geschrieben, sondern „funktioniert schlecht.“
Und dass Tausende von Leuten fehlerhafte Konzepte benutzen, macht die Konzepte nicht richtiger.
Weniger Arroganz. Best practices entwickeln sich nicht aus dem Bauch heraus. Wenn man mit seiner Art und Weise etwas zu tun zur Minderheit gehört, dann ist es meistens nicht so, dass man es besser weiß als der Rest der Branche sondern eher so, dass man mit seiner Art etwas umzusetzen daneben liegt.
Ich nehme jetzt einfach mal an, dass Du mir auf humorvolle Weise sagen wolltest, dass Dich das nicht weiter interessiert?
Fast richtig. Die Session sollte eh nur Daten enthalten, die nicht wichtig sind (etwa die User-ID des Logins, vielleicht nochmal eine Nachricht über den Erfolg oder den Misserfolg der Aktion), das ist kein Zwischenspeicher. Dein „wenn ich mal 2mb in der Session habe“ deutet darauf hin, dass du Sessions missbrauchst. User-Daten gehören nicht in die Session, dafür gibt es andere Techniken (welche angemessen sind, kann ich ohne Hintergrund-Informationen nicht sagen).
SSHFS ist so ziemlich die langsamste und fehleranfälligste Variante, die man sich einfallen lassen kann. Da sind selbst Session-Daten auf einem NFS-Share noch deutlich robuster…
Im abgesicherten LAN-Betrieb mag man gerne unverschlüsselte Techniken benutzen. Vielleicht gibt es auch noch andere Möglichkeiten, Ressourcen im LA-Netzwerk zu teilen, die ich hier jetzt gewiss nicht alle aufzähle.
Wie ich bereits schrieb: es ist generell eine schlechte Idee, concurrent ressources über ein Netzwerk-Share zu verteilen. Das bringt viele Probleme mit sich. Nicht machen, das gibt nur Schmerzen. Wenn man etwas so stark konkurrierendes wie Sessions auf dem Server speichern will, sollte man dafür sowas wie Redis oder Memcached oder so nutzen.
LG,
CK-
Hello,
Ok, Du willst es so!
Das System wäre extrem fehleranfällig!
Nö, funktioniert gut. Wie etwa hier im Forum zu sehen. Und es funktioniert so gut, dass es der best practice ist…
"Funktioniert gut" ist keine Aussage über die Zuverlässigkeit.
Natürlich ist es das. Sonst hätte ich ja nicht „funktioniert gut“ geschrieben, sondern „funktioniert schlecht.“
Nur weil Du den Eindruck hast, ist noch keine Zuverlässigkeit bewiesen. Ich sehe da eine Definitionslücke.
Und dass Tausende von Leuten fehlerhafte Konzepte benutzen, macht die Konzepte nicht richtiger.
Weniger Arroganz.
Genau DAS musste ich leider denken, als ich dein erstes Posting gelesen habe und Du bestätigst diesen Eindruck jetzt nochmal. Wirklich schade!
Best practices entwickeln sich nicht aus dem Bauch heraus.
Nein, oft aus Faulheit und weil ja "noch nie etwas passiert ist".
Wenn man mit seiner Art und Weise etwas zu tun zur Minderheit gehört, dann ist es meistens nicht so, dass man es besser weiß als der Rest der Branche sondern eher so, dass man mit seiner Art etwas umzusetzen daneben liegt.
Wer sagt denn, dass die Leute, die es richtig oder zumindest besser machen, zur Minderheit gehören? Nur weil VIELE es falsch machen, sind sie weder die Mehrheit noch diejenigen die die Weisheit als ihr Geburtsrecht beanspruchen dürfen.
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es
Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.
-
-
-
-
Und wer würde den Softweareersteller überhaupt daran hindern, die Sessiondaten alle zentral auf einem einzigen Netzwerkfileserver im LAN (intrerne Zone) zu halten, auch wenn die Verarbeitung auf unterschiedlichen Hosts stattfindet?
Wenn die Aufgabenstellung für die Serverfarm "Ausfallsicherheit" lautet und nur wenig frequentiert wird, kann man das vielleicht so machen.
Wenn die Serverfarm aber (auch) Lastverteilung bei hohen Nutzerzahlen leisten soll, dann wäre das eine schlechte Idee. Sessiondaten liegen regulär in Dateien und erzeugen womöglich viel und oft I/O, bei dem Ansatz auch noch auf einem zentralen Server über eine Netzwerkanbindung. Das ist ein Flaschenhals, der das Setup schnell lahmlegen kann. Wenn zentral, dann im RAM, mit welchem Tool/Mittel auch immer.
-
-
Inwiefern löst das denn das Problem der Zuordnung?
Silvios Problem ist, dass das alte[tm] Session-Handling die Session-Daten in Dateien geschrieben hat, die dann bei einer Software, die auf mehrere Server verteilt ist, nicht auf allen Servern zugänglich ist. Das Problem gibt es bei dem Ansatz Session-Daten im Cookie nicht mehr: dort sind die Session-Daten im Cookie und werden vom Client bei jedem Request erneut an den Server gesendet. Der muss den Cookie nur noch entschlüsseln und die Signatur überprüfen, und schon sind alle Session-Daten verfügbar.
Danke für die Aufklärung. Das kannte ich so noch nicht und klingt spannend!
-
Hello,
Silvios Problem ist, dass das alte[tm] Session-Handling die Session-Daten in Dateien geschrieben hat, die dann bei einer Software, die auf mehrere Server verteilt ist, nicht auf allen Servern zugänglich ist. Das Problem gibt es bei dem Ansatz Session-Daten im Cookie nicht mehr: dort sind die Session-Daten im Cookie und werden vom Client bei jedem Request erneut an den Server gesendet. Der muss den Cookie nur noch entschlüsseln und die Signatur überprüfen, und schon sind alle Session-Daten verfügbar.
Danke für die Aufklärung. Das kannte ich so noch nicht und klingt spannend!
Das funktioniert, wenn überhaupt, auch nur unter erheblichen Einschränkungen.
Bei verteilten Subrequests (z. B. für Bilder, Filme, Audio je ein eigener Host) gibt's schon Probleme.Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es
Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.
-
Danke für die Aufklärung. Das kannte ich so noch nicht und klingt spannend!
Das funktioniert, wenn überhaupt, auch nur unter erheblichen Einschränkungen.
Das ist sicher kein Ansatz, den man mal einfach so in ein bestehendes System implementieren kann, die Architektur muss schon passen. z.B. Deine 2MB Sessiondaten stünden dem entgegen.
Spannend ist es allemal, nicht nur im Kontext Load-Balancing.
Bei verteilten Subrequests (z. B. für Bilder, Filme, Audio je ein eigener Host) gibt's schon Probleme.
Den Zusammenhang verstehe ich nicht. Auch ein "klassischer" Session-Cookie würde nie an example.net gesendet werden, wenn er für example.org gesetzt wurde.
-
Hello,
Den Zusammenhang verstehe ich nicht. Auch ein "klassischer" Session-Cookie würde nie an example.net gesendet werden, wenn er für example.org gesetzt wurde.
aber an audio.example.org und an video.example.org und an members.example.org ...
Und wo die Aufteilung stattfindet, ist auch egal. Wenn ich die Anfreagen auf mehrere Hosts verteile, egal ob mit oder ohne unterschiedlichen Domainnamen, dann bekomme ich Probleme mit de(m|n) Cookie(s).
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es
Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.
-
Den Zusammenhang verstehe ich nicht. Auch ein "klassischer" Session-Cookie würde nie an example.net gesendet werden, wenn er für example.org gesetzt wurde.
aber an audio.example.org und an video.example.org und an members.example.org ...
Sicher, soweit der Cookie entsprechend gesetzt ist.
Und wo die Aufteilung stattfindet, ist auch egal. Wenn ich die Anfreagen auf mehrere Hosts verteile, egal ob mit oder ohne unterschiedlichen Domainnamen, dann bekomme ich Probleme mit de(m|n) Cookie(s).
Warum? Ich verstehe nicht, wo der Unterschied liegt.
-
Hello,
Warum? Ich verstehe nicht, wo der Unterschied liegt.
Welcher Unterschied?
Du meinst hoffentlich den Unterschied zwischen dem mit Daten belasteten Cookie gegenüber dem reinen Auth-Cookie, der nach Erteilung nicht mehr verändert wird?
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es
Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.
-
Warum? Ich verstehe nicht, wo der Unterschied liegt.
Welcher Unterschied?
Ich verstehe nicht inwiefern die von Christian Kruse skizzierte Vorgehensweise sich bzgl. der von Dir angesprochenen Thematik der Subrequests auf verschiedene Subdomains unterscheiden soll.
-
-
-
-
-
-
-
-
So wie ich das verstehe, werden die Sessiondaten im Cookie gespeichert und damit durch den Browser des Nutzers. Von daher ist die Zuordnung zwischen den Servern egal, da man ja, egal welcher Server den Request annimmt, die Daten aus dem Browser abfragt.
-
-
hast du dazu ein paar konkrete Links? Hatte mal über Fundstellen zu "signed session cookie" drübergeschaut.
-
Hallo chorn,
hast du dazu ein paar konkrete Links? Hatte mal über Fundstellen zu "signed session cookie" drübergeschaut.
Puh, mein Wissen bezieht sich aus Bekannten, die bei Google oder Facebook arbeiten (unterschiedliche Bekannte! ;) und verschiedenen Blog-Einträgen/Artikeln, die ich jetzt nicht mehr recht auswendig weiß.
Aber du kannst dir mal den Session Cookie Store von Rails anschauen - vielleicht hilft das ja schon weiter?
LG,
CK-
hast du dazu ein paar konkrete Links? Hatte mal über Fundstellen zu "signed session cookie" drübergeschaut.
Puh, mein Wissen bezieht sich aus Bekannten, die bei Google oder Facebook arbeiten (unterschiedliche Bekannte! ;) und verschiedenen Blog-Einträgen/Artikeln, die ich jetzt nicht mehr recht auswendig weiß.
Ich habe gerade einen Blog-Post dazu gelesen, der es mir recht anschaulich darlegt, ich hoffe da steht kein Mist ;-) Wenn ich fragen darf, wie geht ihr für die Signatur hier im Forum vor? Ein Secret, was nur der Server kennt? Dann wären bei einem Servereinbruch ja alle Sessions kompromittierbar. Also vermutlich noch mehr?
-
Hallo Mitleser,
Ich habe gerade einen Blog-Post dazu gelesen, der es mir recht anschaulich darlegt, ich hoffe da steht kein Mist ;-)
Ich habe gerade keine Zeit den zu lesen, sorry - ich schau ihn mir in der Mittagspause an.
Wenn ich fragen darf, wie geht ihr für die Signatur hier im Forum vor? Ein Secret, was nur der Server kennt?
Standard-Rails-Weg: ein Secret, dass nur der Server kennt.
Dann wären bei einem Servereinbruch ja alle Sessions kompromittierbar. Also vermutlich noch mehr?
Bei einem Server-Einbruch sind immer alle Sessions kompromittierbar, dabei ist es egal, ob ich sie in einer Datei speichere (die ist dann für den Angreifer zugänglich), in der Datenbank (die Applikation muss ja den Zugang zur DB kennen und damit ist sie für den Angreifer zugänglich) oder in einem Store wie Memcached/Redis (hier gilt das gleiche wie für die Datenbank). Da lässt sich nach meinem Kenntnisstand nichts dran ändern.
LG,
CK
-
-
-
-
-
Hi,
eine Session must Du gar nicht in einer Datenbank speichern. Die wird zwischen Server und Client ausgehandelt, der Client speichert den Keks (Cookie) mit der ausgehandelten Session ID, fertig.
Ausführlich hier beschrieben, solange der Client den Cookie nicht löscht und immer dieselbe ID sendet, bleibt die Sesssion bestehen. D.h., da ist es auch völlig egal welcher der Server die Response ausliefert, die Session ist davon unabhängig.
Erst dann, wenn es in der Session was zu speichern gibt, ein erfolgreicher Login z.B. oder ein Warenkorb, dann gehts an Speichern serverseitig. Logisch dass bei mehreren Servern diese Speicherung zentralisiert werden muss.
MfG
-
Hello,
eine Session must Du gar nicht in einer Datenbank speichern.
Hier ging es um die Zur Session gehörenden Daten.
Die wird zwischen Server und Client ausgehandelt, der Client speichert den Keks (Cookie) mit der ausgehandelten Session ID, fertig.
Man möchte aber schon gerne sicherstellen, dass nicht aus versehen (wegen der Netzwerk-Laufzeiten) eine Racecondition entsteht und der Client sich mehrere Sessions-Identifier aushandelt (mit jedem Host, auf den seine SUB-Requests aus EINEM Hauptdokument verteilt werden)!
Die Zentralisierung und "Atomarisierung" der "Get-Session-Identifier"-Anfrage auf eine einzige Senke sollte daher sichergestellt werden.
Ausführlich hier beschrieben, solange der Client den Cookie nicht löscht und immer dieselbe ID sendet, bleibt die Sesssion bestehen.
Das ist aber im realen Leben und HTTP-Requests über Load-Balancing nicht sichergestellt, wenn man nicht genauer darüber nachdenkt, bevor man 'was zusammenbaut.
D.h., da ist es auch völlig egal welcher der Server die Response ausliefert, die Session ist davon unabhängig.
Sollte sein! Das muss aber die Programmlogik nebst Datenhaltung sicherstellen!
Erst dann, wenn es in der Session was zu speichern gibt, ein erfolgreicher Login z.B. oder ein Warenkorb, dann gehts an Speichern serverseitig. Logisch dass bei mehreren Servern diese Speicherung zentralisiert werden muss.
Wenn es nichts zu erkennen (Auth) oder zu speichern gäbe, bräuchte man gar keine HTTP-Session-Verwaltung.
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es
Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.
-
Hi Tom,
Entscheidend für das Zustandekommen einer Session ist, dass der Browser im Request Header einen Cookie sendet. Das kannst Du hier prüfen und siehe da, das hat mit verteilten Servern und Laufzeiten überhaupt nichts zu tun. Infolgedessen gibt es auch keine Racecondition.
Wenn es nichts zu erkennen (Auth) oder zu speichern gäbe, bräuchte man gar keine HTTP-Session-Verwaltung.
Wenn Du keine Session hast, kannst Du auch kein Login oder einen Warenkorb speichern. Und auch hier haben wir wieder die Bestätigung oben getroffner Aussage: Der Client speichert die Session.
Ob der Client auch die Daten (im Cookie) speichert, ist eine ganz andere Frage, nämlich eine Frage der Datenkonsistenz. MfG
-
Hello,
Entscheidend für das Zustandekommen einer Session ist, dass der Browser im Request Header einen Cookie sendet. Das kannst Du hier prüfen und siehe da, das hat mit verteilten Servern und Laufzeiten überhaupt nichts zu tun. Infolgedessen gibt es auch keine Racecondition.
Den Cookie muss er aber zuvor vom Server beziehen.
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es
Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.
-
Den Cookie muss er aber zuvor vom Server beziehen.
Nein muss er nicht. Ich hab Dir doch erklärt warum. MfG
-
-
-
-
[...] Logisch dass bei mehreren Servern diese Speicherung zentralisiert werden muss.
Nein. Eine weitere Möglichkeit wären Sticky Sessions. Heute morgen hat Christian Kruse eine weitere Variante beschrieben, die ich noch nicht kannte, aber von der ich weiter recht angetan bin.
-