1UnitedPower: Letzt Useraktivität erkennen

Beitrag lesen

Meine Herren!

Wessen Instanz, wessen Kinder? Das Session-Cookie verfällt, wenn sein Verfallsdatum abgelaufen ist, nicht früher nicht später. Es kann aber passieren, dass das Cookie eine Session-ID trägt, die auf dem Server nicht mehr existiert.

Wo wird das Cookie denn angelegt? Dort verfällt es auch!

Bingo. Und wenn es verfällt, gibt es keinen mehr, der die Session-ID kennt. Die Session ist damit unerreichbar. Das verfolgte Ziel des Fragestellers ist erreicht.

Es muss nicht "kurz eingestellt" werden, denn es steht schon bei "0".

"0" ist kein gültiger Wert für expires. Für max-age kann man "0" angeben, das bedeutet aber, dass das Cookie bereits ungültig ist, weil das Ablaufdatum auf einen implementationsabhängigen Zeitpunkt in der Vergangenheit verweist. Für die meisten Implementation dürfte das dann wohl der Start der UNIX-Epoche sein.

Guckst Du unter "transienter Cookie" im Gegensatz zu "persistenter Cookie". Googlen musst Du bitte mal alleine.

Können wir keinen freundlichen Ton wahren? Ich habe im RFC 6265 nachgeschlagen, du kannst es da gerne selber nachlesen. Dass du auf transiente Cookies hinaus wolltest, war mir nicht klar. Und erlaube mir zu urteilen, dass deine Beschreibung auch irreführend war.

Aber ich gebe dir Recht, mit transienten Cookies kann das Problem auch gelöst werden. Allerdings führt ein Browser-Neustart dann stets zu einem Verlust der Sitzung.

Wenn wir den wegoperierten bidirektionalen Dialog aus TCP in HTTP zumindest halbseitig wieder emulieren wollen

Jetzt habe ich den Faden verloren, reden wir immer noch über Sessions?

Wir reden über Sessions.
Mit TCP kann man eine Session sehr leicht kontrollieren, da beide Partner jederzeit feststellen können, ob der andere noch da ist.

Eine Session stellt die etablierte zustandsorientierte Verbindung zwischen (zwei) (gleichberechtigten)  Kommunikationspartern dar. TCP ermöglicht dies. In HTTP ist diese Fähigkeit "wegoperiert"; dort gibt es dedizierte Clients und Server.

Und es gibt eben Sessions, wie sie nativ in PHP implementiert sind, und die wir nicht neu implementieren müssen. Es existiert bereits eine Abstraktionsebene, um Sitzungen über mehrere HTTP-Roundturns zu simulieren, eine Diskussion über die TCP-Grundlagen empfinde ich an dieser Stelle als müßig.

Außerdem könnten andere teilnehmer bereits Hinweise darauf bekommen, dass dieser Teilnehmer schon auf "gelb" steht, noch bevor dessen Session abläuft.

Beschreibe das Szenario, das du hier für problematisch hältst bitte mal etwas genauer. Ich kann dir nicht ganz folgen.

Im Archiv findest Du dazu von mir genügend Beschreibungen.

Meine Suche nach "Tom gelb" blieb recht erfolglos. Wenn du nicht bereit bist, über diese Punkt zu diskutieren, solltest du ihn vielleicht nicht zur Sprache bringen. Nachhaken ist in diesem Forum eben üblich.

--
“All right, then, I'll go to hell.” – Huck Finn