Cookieakzeptanz des Browsers per PHP feststellen?

[J.Hahn]

N'Abend allerseits,

ich möchte statt der Session-Funktionalität von PHP meine eigene Klasse für eine Session-Verwaltung in einem Webshop verwenden. Diese Klasse speichert die Session-ID als Cookie, bzw. hängt sie an die Seiten-URLs (shop.php?sid=12345678), fals der Browser keine Cookies akzeptiert.
Ob der Browser Cookies annimmt oder nicht, stelle ich in der Klasse mit einer einfachen Abfrage der Superglobalen $_COOKIES['sid'] fest.

Blöd bei dieser Variante ist allerdings, dass der Besucher beim ersten Seitenaufruf natürlich keine Session-ID als Cookie auf seinem Rechner gespeichert haben kann, egal ob der Browser nun welche akzeptiert oder nicht. Ich habe hier auch gelesen, dass es wohl nicht möglich ist, per PHP einen Cookie zu senden und im selben PHP-Skript festzustellen, ob dieser Cookie auch wirklich beim Client gespeichert worden ist.

Allerdings: Es muss wohl irgendwie gehen, da es die PHP-interne Sessionbehandlung auch kann. Außerdem funktioniert das auch z.B. im Webshop von Titus (http://www.titus.de) .

Ist es möglich, dass ein Cookie per Header statt per "setcookie();" gesetzt werden muss und dass man dann irgendeine Antwort vom Client/ Browser bekommen kann??

Danke für die Hilfe und schöne Grüße, Josef

[Manuel B.]

Ich grüsse den Cosmos,

Ist es möglich, dass ein Cookie per Header statt per "setcookie();" gesetzt werden muss und dass man dann irgendeine Antwort vom Client/ Browser bekommen kann??

Eine Antwort vom Browser beko0mmst du evtl. schon, aber nicht, ob der Cookie gesetzt wurde.
Du kannst ihn lediglich wieder auslesen. Und wenn das nicht geht, wurde er nicht akzeptiert.

Möge das "Self" mit euch sein

[Der Martin]

Hallo,

Blöd bei dieser Variante ist allerdings, dass der Besucher beim ersten Seitenaufruf natürlich keine Session-ID als Cookie auf seinem Rechner gespeichert haben kann, egal ob der Browser nun welche akzeptiert oder nicht. Ich habe hier auch gelesen, dass es wohl nicht möglich ist, per PHP einen Cookie zu senden und im selben PHP-Skript festzustellen, ob dieser Cookie auch wirklich beim Client gespeichert worden ist.

das ist richtig, um ein Cookie wieder auszulesen, ist immer ein Round Trip erforderlich.

Allerdings: Es muss wohl irgendwie gehen, da es die PHP-interne Sessionbehandlung auch kann.

Ich habe keine Ahnung, wie es da realisiert ist. Aber ich würde mal versuchen, beim ersten Aufruf nur ein Redirect per Location-Header auszulösen und gleichzeitig das Cookie zu setzen.
Die Ressource, die durch den Redirect aufgerufen wird, kann das Cookie dann sofort auswerten.

Ist es möglich, dass ein Cookie per Header statt per "setcookie();" gesetzt werden muss ...

Nein, das ist beides dasselbe - setcookie() fügt auch nur einen Response Header zum Cookie-Setzen hinzu.

So long,
 Martin

[wahsaga]

hi,

ich möchte statt der Session-Funktionalität von PHP meine eigene Klasse für eine Session-Verwaltung in einem Webshop verwenden.

Warum?
Was soll die können, was PHP nicht mindestens genauso gut könnte?

Allerdings: Es muss wohl irgendwie gehen, da es die PHP-interne Sessionbehandlung auch kann.

Nein, das hast du geträumt.

Auch PHP hängt beim intialen Start der Session die Session-ID als GET-Parameter an site-interne Links an und fügt sie als hidden field in POST-Formulare ein - und setzt gleichzeitig einen Cookie mit der Session-ID [1].
Erst beim nächsten Request kann dann entschieden werden, ob Cookie für den Rest der Sitzung mit ausreichender Wahrscheinlichkeit als "funktionierend" angesehen werden kann, oder ob weiterhin die explizite Weitergabe im Quellcode erfolgen muss.

[1] Defaultkonfiguration

gruß,
wahsaga

[dedlfix]

echo $begrüßung;

Erst beim nächsten Request kann dann entschieden werden, ob Cookie für den Rest der Sitzung mit ausreichender Wahrscheinlichkeit als "funktionierend" angesehen werden kann, oder ob weiterhin die explizite Weitergabe im Quellcode erfolgen muss.

Eine kleine Korrektur: "Nächster Request" ist bei HTTP irrelevant. PHP merkt sich auch zwischen den Requests nichts. In der Session-Datei werden nur die in $_SESSION enthaltenen Daten abgelegt. Weitere Informationen zum Zustand der Session werden nicht festgehalten *). Der Mechanismus ist wohl eher so, dass PHP generell die Session-ID im Cookie erwartet, und wenn es keins bekommt der Ersatzmechanismus aktiviert wird, so wie das beim "ersten" Request der Fall ist.

*) vom Dateidatum mal abgesehen, das vom Garbage Collector ausgewertet wird

echo "$verabschiedung $name";

[wahsaga]

hi,

Eine kleine Korrektur: "Nächster Request" ist bei HTTP irrelevant.

In wie fern?

PHP merkt sich auch zwischen den Requests nichts. In der Session-Datei werden nur die in $_SESSION enthaltenen Daten abgelegt.

Das ist klar.

Der Mechanismus ist wohl eher so, dass PHP generell die Session-ID im Cookie erwartet, und wenn es keins bekommt

• dann wird sie in den GET/POST-Parametern gesucht -

der Ersatzmechanismus aktiviert wird, so wie das beim "ersten" Request der Fall ist.

Der Fallback der SID-Übergabe im Quellcode kommt dann wieder zum Zuge, falls keine per Cookie übergeben wurde, ja.
Und wenn gar keine übergeben wurde, dann geht's bei session_start() wieder von vorne los - mit neuer Session-ID.

gruß,
wahsaga

[dedlfix]

echo $begrüßung;

"Nächster Request" ist bei HTTP irrelevant.
In wie fern?

Ein Request ist ein abgeschlossener Vorgang. Es existiert aus der Sicht des aktuellen Geschehens (also z.B. Logfiles nicht betrachtend) im Server nach Abschluss eines Requests im Prinzip keinerlei Information mehr über ihn. Das würde einen Server zu sehr belasten, wenn er sich auch noch darüber Notizen machen muss, zumal er gar nicht weiß, ob, wann und von welcher Quelle der "nächste" Request zu erwarten ist.

Der Mechanismus ist wohl eher so, dass PHP generell die Session-ID im Cookie erwartet, und wenn es keins bekommt

• dann wird sie in den GET/POST-Parametern gesucht -

Ja, dann hat PHP erstmal eine Session-ID für den aktuellen Request, aber darum geht es ja in dieser Diskussion nicht, sondern um die Weitergabe zwischen den Requests. Und da muss PHP nur wissen, ob es einen Keks gab oder nicht, um zu entscheiden, ob Trans-SID für die aktuelle Response Verwendung findet.

echo "$verabschiedung $name";

[wahsaga]

hi,

Ein Request ist ein abgeschlossener Vorgang.

Ja, schon klar - nur "irrelevant" finde ich merkwürdig formuliert.

Ja, dann hat PHP erstmal eine Session-ID für den aktuellen Request, aber darum geht es ja in dieser Diskussion nicht, sondern um die Weitergabe zwischen den Requests. Und da muss PHP nur wissen, ob es einen Keks gab oder nicht, um zu entscheiden, ob Trans-SID für die aktuelle Response Verwendung findet.

Jepp, einverstanden.

gruß,
wahsaga

[J.Hahn]

Was soll die können, was PHP nicht mindestens genauso gut könnte?

... anschließend viele tolle Datenbankoperationen, die eben nur für das Shopsystem wichtig sind ;-)

Nun, aber warum das mit der Cookieerkennung beim Titus-Shop (again: http://www.titus.de) doch funktioniert, ist mir immernoch schleierhaft!?? Any idea??

Grüße, Josef

[wahsaga]

hi,

Was soll die können, was PHP nicht mindestens genauso gut könnte?
... anschließend viele tolle Datenbankoperationen, die eben nur für das Shopsystem wichtig sind ;-)

Was haben die direkt mit der Sessionverwaltung zu tun?
Gar nichts, möchte man meinen.

Nun, aber warum das mit der Cookieerkennung beim Titus-Shop (again: http://www.titus.de) doch funktioniert, ist mir immernoch schleierhaft!??

Was funktioniert denn da bitte wo?

Any idea??

Wenn ich die Annahme von Cookies deaktiviere, dann gelange ich auf Adressen wie
http://www.titus.de/SID=sifd4126e12345678912345678901234/screen.phtml?parameter...

Auch da wird also die SID per GET übertragen - nur nicht als Querystring-Parameter, sondern Pfad-Bestandteil - mod_rewrite o.ä. machst möglich.

gruß,
wahsaga

[J.Hahn]

Was haben die direkt mit der Sessionverwaltung zu tun?
Gar nichts, möchte man meinen.

... möchte man, muss man nicht. Nun, ich möchte u.a. nicht, dass da PHPSESSID oder ähnliches, defaultmäßiges in der URL steht. Und, bevor noch ein Einwand kommt: Ich kann auf dem Webspace nicht an die PHP.INI ran und mod_rewrite gibt es auch nicht. Jetzt zufrieden? ;-)

[Blaubart]

Tach.

Nun, aber warum das mit der Cookieerkennung beim Titus-Shop (again: http://www.titus.de) doch funktioniert, ist mir immernoch schleierhaft!?? Any idea??

Die Startseite versucht auch Cookies zu setzen, leitet sofort an /index.phtml weiter und von dort entweder weiter nach /screen.phtml, falls ich die Session-ID im Cookie beim Request mitschicke oder zu /SID=tolle_session_id/screen.phtml, falls ich ohne Cookie antworte. Siehe Martins Antwort.

[J.Hahn]

... danke für den Hinweis, hatte ich leider übersehen :-(. So funktioniert das zwar, verfälscht dann allerdings die Statistik ordentlich, da ja mindestens eine Seite einer Session immer doppelt aufgerufen wird. Na gut, ich seh schon, alles kann man nicht haben ;-)...

Grüße, Josef