[laborix]

Hallo miteinander,

nur eine kleine Frage. Warum erzeugen ein Apache oder IIS ein Cookie im Browser, wenn man mit PHP ein "session_start()" aufruft? Apache und IIS legen im "temp/tmp" ebenfalls ein "sess_..." ab, warum muss der Client dann auch ein Cookie mit der Session ID bekommen?

Irgendwie finde ich keine Antwort, warum das so ist. Habe ihr eine plausible Erklärung für dieses Verhalten?

[mermshaus]

HTTP ist ein zustandsloses Protokoll.

- Zustandslosigkeit

Würde kein Cookie mit einer Session-ID immerzu mit übertragen, könnte der Server nicht zuordnen, welche Sessiondaten zu einer Anfrage gehören.

[mantiz]

Marc hat es ja schon geschrieben, aber vielleicht noch etwas detaillierter:

Ein Cookie sind Daten, die bei dem Client gespeichert werden, Session-Daten sind Daten, die auf dem Server gespeichert werden. Da HTTP ein zustandsloses Protokoll ist, wie Marc schrieb, muss der Server den Client ja irgendwie wiedererkennen. Dies wird dadurch erreicht, dass eine Session-ID in einem Cookie gespeichert wird, über diese Session-ID kann dann die Session auf dem Server und somit sämtliche Daten, die auf dem Server zu dieser Session gespeichert wurden, eindeutig zugeordnet werden.

Die Session hat das Cookie also in soweit abgelöst, dass das Cookie nur noch für die Session-ID verwendet wird, die Daten aber "sicherer" auf dem Server gespeichert werden und nicht mehr beim Client selbst.

[laborix]

Sorry für die späte Reaktion, bin voll im Weihnachtsstress

Danke euch beiden, dass Hintergrundwissen hat mir gefehlt. Nun stellt sich aber die Frage, ob man eine Session per Default laufen lässt oder erst bei bedarf?

Beispiel: Login-System und Backend Administration eines Blog/CMS ist Session Handling ein "must have".

Sollte aber alles andere ohne Session laufen? Wobei sich hier auch wieder die Frage stellt, wie viele Internet Benutzer ein (PHP Session ID)Cookie auf "Fragen" oder "deaktiviert" gesetzt haben?

[mantiz]

Wenn du die Session immer startest (session_start), dann wird die Session fortgesetzt, sofern eine gültige Session-ID vom Client geschickt wird. Wird keine gültige Session-ID geschickt, so wird eine neue Session gestartet.

Wird ein Session-Cookie nicht akzeptiert, so wird einfach bei jedem neuen Request eine neue Session gestartet, so einfach ist das.

Die Frage ist halt, ob du den "Overhead" einer Session haben möchtest, wenn es nicht unbedingt erforderlich ist. Wenn du zwischen session-basierten Requests und session-losen Requests unterscheidest, musst du darauf achten, dass du "session_start" entsprechend nur bei den Requests aufrufst, die unter einer Session laufen sollen.

Ich mache es mir da einfach und starte einfach immer eine Session. Man kann ja auch abgesehen von der Authentifizierung nützliche Daten in einer Session speichern (z.B. Suchbegriffe, Sortierungen, Warenkorb, etc.). Akzeptiert jmd. das Cookie nicht, dann kann er halt von diesen Features keinen Gebrauch machen, aber ansonsten funktioniert trotzdem alles.

Die Frage ist, wann soll der User darüber informiert werden, dass das eine oder andere evtl. nur mit akzeptiertem Cookie funktioniert. Ich mache es mir da einfach und setze einfach voraus, dass das Session-Cookie akzeptiert wird, wenn nicht, dann ist man selber schuld.

[Praktikant]

Die EU sagt bei Cookies: So wenig wie möglich, so viele wie nötig und wenn es sich nicht um eine Funktion wie einen Warenkorb oder eine Anmeldung handelt, die ohne Kekse nicht zu realsieren sind, dann kann man sie setzen.
Informieren muss man immer darüber, in allen anderen Fällen bevo de Keks gesetzt wird.

Hier eine Quelle: heise online - Datenschützer erläutern rechtskonformen Cookie-Einsatz

[laborix]

Zitat von mantiz

... Ich mache es mir da einfach und starte einfach immer eine Session. Man kann ja auch abgesehen von der Authentifizierung nützliche Daten in einer Session speichern (z.B. Suchbegriffe, Sortierungen, Warenkorb, etc.). ...

Ist das in PHP Developer Kreisen die bevorzugte Methode?

Zitat von Praktikant

... Informieren muss man immer darüber, in allen anderen Fällen bevo de Keks gesetzt wird. ...

Wie setzt du das um? Ist ein Keks für Suchergebnisse gerechtfertigt?

[mantiz]

Zitat von laborix

Ist das in PHP Developer Kreisen die bevorzugte Methode?

Ich denke eher nicht, ich hab's bisher lediglich aus Bequemlichkeit gemacht.

Nach Praktikant's Einwand überlege ich mir gerade allerdings wie ich das bei mir einbaue.

Nur kurz zur Info:
Wenn du die Session wirklich zerstören möchtest, dann reicht ein simples

PHP-Code:

session_destroy(); 


nicht aus, es muss auch das Cookie gelöscht werden, z.B. mit

PHP-Code:

setcookie(session_name(), session_id(), 1, '/');
session_destroy(); 


Ansonsten bleibt das Cookie nämlich beim Client aktiv und dieser sendet weiterhin die SessionID.

Wenn das Cookie gelöscht wird/werden kann, dann kann man einfach prüfen, ob das Cookie vom Client gesendet wird und ggfs. die Session automatisch wieder aufnehmen. Ist die Session nicht aktiv, so kann ein Link (oder so) angezeigt werden, wo über die Features informiert wird und ggfs. die Session vom Benutzer manuell gestartet werden kann.

Gefällt mir ganz gut, ich glaub' ich bau' das so ein.

[mermshaus]

Zitat von laborix

Ist das in PHP Developer Kreisen die bevorzugte Methode?

Immer eine Session zu starten? Na ja, sobald du etwa ein dynamisches Seitenelement hast, das sich je nach Login-Status verändert („Sie sind nicht eingeloggt/eingeloggt als xy.“), kommst du nicht wirklich dran vorbei, eine Session zu starten.

Wie setzt du das um? Ist ein Keks für Suchergebnisse gerechtfertigt?

Das ist schwer pauschal zu beantworten. Im Grunde ist eine Suchanfrage aber ein klassischer GET-Request, da tendenziell idempotent. Anders gesagt: Alle relevanten Informationen sollten idealerweise im URL stecken, um etwa Verlinkbarkeit oder Abspeicherbarkeit (Bookmark) zu gewährleisten. Das ist meist, aber eben auch nicht immer, ein wünschenswertes Feature.

[mantiz]

Zitat von mermshaus

Immer eine Session zu starten? Na ja, sobald du etwa ein dynamisches Seitenelement hast, das sich je nach Login-Status verändert („Sie sind nicht eingeloggt/eingeloggt als xy.“), kommst du nicht wirklich dran vorbei, eine Session zu starten.

Genau wegen solcher Situationen habe ich das bisher ebenfalls eher bequem gelöst und dann einfach immer eine Session gestartet. Allerdings ist es tatsächlich kein allzu großer Akt die Session nur nach Bedarf zu starten.

Zitat von mermshaus

Das ist schwer pauschal zu beantworten. Im Grunde ist eine Suchanfrage aber ein klassischer GET-Request, da tendenziell idempotent. Anders gesagt: Alle relevanten Informationen sollten idealerweise im URL stecken, um etwa Verlinkbarkeit oder Abspeicherbarkeit (Bookmark) zu gewährleisten. Das ist meist, aber eben auch nicht immer, ein wünschenswertes Feature.

Natürlich sollten solche Dinge auch nur ergänzend genutzt werden. Im Falle der Suche beispielsweise wird dann beim Aufruf der Suchseite per header() auf die in der Session gespeicherte Seite weitergeleitet. Ich finde es ist ein nettes Feature, wenn ich auf einer Seite etwas suche, dann ein wenig auf der Seite rumsurfe und wieder die Suche öffne, ich wieder die Ergebnisse meiner letzten Suche angezeigt bekomme.
In Zukunft werde ich in solchen Fällen aber wohl nicht automatisch eine Session starten, sondern je nach Session-Status einen Hinweistext anzeigen, der kurz erläutert, dass eine Session gestartet werden kann und welchen Nutzen man davon hat.