Mahlzeit, bin ich hier mit PHP richtig? Folgendes Problem: PHP ist Neuland für mich. Ok, ein bisschen ausführlicher: Ich möchte gerne eine Session-Variable mit mir herumschleppen: <?PHP session_start(); if (!isset($_SESSION["pages_visited"])){$_SESSION["pages_visited"]="0";} ... ?> Auf den nun folgenden Seiten (max. vier) wird diese Variable immer länger: <?PHP session_start(); ... $_SESSION["pages_visited"] .=$page_id; ... ?> Am Ende der Sitzung bekomme ich mit dem Konqueror reproduzierbar das richtige Ergebnis. Von Überall in der Welt. Jeder einzelne dusselige Browser unter Windows (98, 2000, XP) hingegen bekommt das mit der Session nicht hin. Am Ende ist die Variable leer. Eigentlich würde ich jetzt sagen, der Inhalt von $_SESSION... wird offenbar nicht übergeben. Nun werden ja aber üblicherweise die Session-Variablen serverseitig gespeichert, der Browser sollte da doch überhaupt nichts mit zu tun haben, oder? Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
Moin Martin, Am Samstag, 14. Juni 2003 16:09 schrieb Martin Borchert:
Nun werden ja aber üblicherweise die Session-Variablen serverseitig gespeichert, der Browser sollte da doch überhaupt nichts mit zu tun haben, oder?
hmmm, lies Dir am besten 'mal http://www.php.net/manual/en/ref.session.php durch, da solltest Du Deine Fragen geklärt bekommen. Relevant dürfte insbesondere session.cookie.*, session.use_cookies und session.use_only_cookies sein, denn die Cookies werden nicht Serverseitig, sondern im Browser gespeichert ... bis denn ... /Frank/
Am Samstag, 14. Juni 2003 16:19 schrieb Frank Röske:
Am Samstag, 14. Juni 2003 16:09 schrieb Martin Borchert:
Nun werden ja aber üblicherweise die Session-Variablen serverseitig gespeichert, der Browser sollte da doch überhaupt nichts mit zu tun haben, oder? hmmm, lies Dir am besten 'mal http://www.php.net/manual/en/ref.session.php durch, da solltest Du Deine Fragen geklärt bekommen. Relevant dürfte insbesondere session.cookie.*, session.use_cookies und session.use_only_cookies sein, denn die Cookies werden nicht Serverseitig, sondern im Browser gespeichert
Ich hab mir das mal angetan und ein bisschen herumexperimentiert. Ich habe also im wesentlichen fünf Möglichkeiten, meine Variablen von Seite zu Seite zu schleifen. 1. Verewigung in der html-Seite als Querystring, hidden formfields 2. Als Cookie 3. Mit dem Array $_SESSION 4. Mit dem Array $HTTP_SESSION_VARS 5. Mit session_register() 1. und 2. finde ich suboptimal weil sehr leicht manipulierbar. 3.-5. sind allesamt ähnlich. Variablen werden linearisiert auf dem Server gespeichert, der Browser muss sich um nichts kümmern. Was mir nicht so ganz klar ist, wie werden die Sessions auseinandergehalten? Ich bin davon ausgegangen, dass php das Session Management übernimmt. Wenn ein Cookie nicht funktioniert, dann eben über $SESSID in $QUERY_STRING. Faslhc? Mir ist der Wirkmechanismus der letzten drei überhaupt nicht klar. Mein Ergebnis war in etwa: $HTTP_SESSION_VARS funktioniert in Abhängigkeit vom Browser (Konqueror/Linux tut, Opera/Win32 tut, IE6 tut nicht, Mozilla/win32 tut nicht) $_SESSION funktioniert in Abhängigkeit des Betriebssystems (Konqueror/Linux tut, */Win32 tut nicht) session_register() tut immer, unabhängig von Browser und Betriebssystem. Im PHP-Manual hab ich dazu keine tieferen Informationen gefunden. Kann aber auch sein, dass ich nicht an den richtigen Stellen gesucht habe. :( -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
Hallo mb, hallo Leute, vorweg: würdest Du bitte Deinen Realname im Absender angeben? Ich weiß nämlich ganz gern, wem ich gerade helfe ;-) Am Montag, 16. Juni 2003 11:05 schrieb mb@kuhtor.net:
[...] 3. Mit dem Array $_SESSION 4. Mit dem Array $HTTP_SESSION_VARS 5. Mit session_register() [...] 3.-5. sind allesamt ähnlich. Variablen werden linearisiert auf dem Server gespeichert, der Browser muss sich um nichts kümmern. Was mir nicht so ganz klar ist, wie werden die Sessions auseinandergehalten? Ich bin davon ausgegangen, dass php das Session Management übernimmt. Wenn ein Cookie nicht funktioniert, dann eben über $SESSID in $QUERY_STRING. Faslhc?
Im Prinzip richtig. Allerdings muss der Fallback auf den Querystring aktiv sein. (--enable-trans-sid beim Compilieren)
Mir ist der Wirkmechanismus der letzten drei überhaupt nicht klar. Mein Ergebnis war in etwa: $HTTP_SESSION_VARS funktioniert in Abhängigkeit vom Browser (Konqueror/Linux tut, Opera/Win32 tut, IE6 tut nicht, Mozilla/win32 tut nicht)
Seltsam. Sessions sollten eigentlich Browser-unabhängig sein, da sie serverseitig verwaltet werden. Der Browser sieht nur die Session-ID. Kann es sein, dass in den nicht funktionierenden Browsern Cookies ausgeschaltet sind? Dann hilft wohl 29.4. Wie übergebe ich Session-IDs ohne Cookies an eine andere Seite? Was ist Fallback? http://www.dclp-faq.de/q/q-sessions-fallback.html
$_SESSION funktioniert in Abhängigkeit des Betriebssystems (Konqueror/Linux tut, */Win32 tut nicht)
Meinst Du jetzt verschiedene PHP-Versionen oder greifst Du immer auf denselben Server zu (mit verschiedenen Clients)? $_SESSION gibt es AFAIK erst ab PHP 4.1, ebenso wie $_GET und $_POST.
session_register() tut immer, unabhängig von Browser und Betriebssystem.
Dann nimm doch das *g* Ansonsten kannst Du ja auch mal durch die o. g. FAQ blättern, da stehen noch mehr interessante Dinge drin ;-) Ich hab bisher nix mit Sessions gebastelt, kann Dir also nur bedingt weiterhelfen. Gruß Christian Boltz -- F: Word? Was ist das? A: Das ist wohl das Programm, das ursrpünglich einmal Text heißen sollte. Da es aber für längere Dokumente ungeeignet ist, wurde es umbenannt. Inzwischen kann es aber bereits 97 Wörter verwalten.
Am Samstag, 21. Juni 2003 01:18 schrieb Christian Boltz:
vorweg: würdest Du bitte Deinen Realname im Absender angeben? Ich weiß nämlich ganz gern, wem ich gerade helfe ;-)
Hmmm... Steht doch drin... Eigentlich. KMail kaputt? Muss ich mal verfolgen. Aber danke für den Hinweis.
Am Montag, 16. Juni 2003 11:05 schrieb mb@kuhtor.net:
[...] 3. Mit dem Array $_SESSION 4. Mit dem Array $HTTP_SESSION_VARS 5. Mit session_register() [...] 3.-5. sind allesamt ähnlich. Variablen werden linearisiert auf dem Server gespeichert, der Browser muss sich um nichts kümmern. Was mir nicht so ganz klar ist, wie werden die Sessions auseinandergehalten? Ich bin davon ausgegangen, dass php das Session Management übernimmt. Wenn ein Cookie nicht funktioniert, dann eben über $SESSID in $QUERY_STRING. Faslhc? Im Prinzip richtig. Allerdings muss der Fallback auf den Querystring aktiv sein. (--enable-trans-sid beim Compilieren)
Jepp, ist aktiviert.
Mir ist der Wirkmechanismus der letzten drei überhaupt nicht klar. Mein Ergebnis war in etwa: $HTTP_SESSION_VARS funktioniert in Abhängigkeit vom Browser (Konqueror/Linux tut, Opera/Win32 tut, IE6 tut nicht, Mozilla/win32 tut nicht) Seltsam. Sessions sollten eigentlich Browser-unabhängig sein, da sie serverseitig verwaltet werden. Der Browser sieht nur die Session-ID. Kann es sein, dass in den nicht funktionierenden Browsern Cookies ausgeschaltet sind? Dann hilft wohl
Nö, ist definitiv bei allen angewesen. Kann es sein, dass die Win-Browser kaputte Cookies zurückgeliefert haben?
29.4. Wie übergebe ich Session-IDs ohne Cookies an eine andere Seite? Was ist Fallback? http://www.dclp-faq.de/q/q-sessions-fallback.html
Fallback hätte eigentlich nicht nötig sein sollen, PHP-seitig war es aber aktiviert.
$_SESSION funktioniert in Abhängigkeit des Betriebssystems (Konqueror/Linux tut, */Win32 tut nicht) Meinst Du jetzt verschiedene PHP-Versionen oder greifst Du immer auf denselben Server zu (mit verschiedenen Clients)?
Sowohl als auch. PHP 4.2.2 von SuSE 8.1 und 4.0.6 von SuSE-7.weißichnich.
$_SESSION gibt es AFAIK erst ab PHP 4.1, ebenso wie $_GET und $_POST.
Ja, aber da hätte dann doch $HTTP_SESSION_VARS tun müssen. War aber nicht.
session_register() tut immer, unabhängig von Browser und Betriebssystem. Dann nimm doch das *g*
Hab ich nun auch. Aber mir ist der Grund nicht klar, warum das funktioniert und der andere Kram nicht. Ich hatte mir Aufklärung über die Mechanismen dahinter erhofft. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
Hallo, On Sat, 21 Jun 2003, Martin Borchert wrote:
Am Samstag, 21. Juni 2003 01:18 schrieb Christian Boltz:
vorweg: würdest Du bitte Deinen Realname im Absender angeben? Ich weiß nämlich ganz gern, wem ich gerade helfe ;-)
Hmmm... Steht doch drin... Eigentlich. KMail kaputt? Muss ich mal verfolgen. Aber danke für den Hinweis.
In der Mail, auf die CB sich bezogen hat nicht -- jetzt scheint's wieder zu klappen... -dnh, der seinen deterministischen MUA liebt ;) Die "Re: Re:" neulich von mir nebenan waren ganz allein meine Schuld (hatte ne RE vermurkst) ;( -- In the middle of evil there's allways *vi* -- snarfed from "Sensor"
Am Samstag, 21. Juni 2003 02:07 schrieb David Haller:
On Sat, 21 Jun 2003, Martin Borchert wrote:
Am Samstag, 21. Juni 2003 01:18 schrieb Christian Boltz:
vorweg: würdest Du bitte Deinen Realname im Absender angeben? Ich weiß nämlich ganz gern, wem ich gerade helfe ;-) Hmmm... Steht doch drin... Eigentlich. KMail kaputt? Muss ich mal verfolgen. Aber danke für den Hinweis. In der Mail, auf die CB sich bezogen hat nicht -- jetzt scheint's wieder zu klappen... -dnh, der seinen deterministischen MUA liebt ;)
Ich hab's rekonstruiert. War ein Layer-8-Problem und trat im Zusammenspiel von sekundären E-Mail-Adressen, dem Abweisen selbiger durch den Listenmanager und dem darauf folgenden halbherzigen Ändern der benutzten Identität auf. Mein KMail verhält sich seit Jahren rock solid und berechenbar. :) Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
Hallo Martin, hallo Leute, Am Samstag, 21. Juni 2003 01:48 schrieb Martin Borchert:
Am Samstag, 21. Juni 2003 01:18 schrieb Christian Boltz:
vorweg: würdest Du bitte Deinen Realname im Absender angeben? Ich weiß nämlich ganz gern, wem ich gerade helfe ;-)
Hmmm... Steht doch drin... Eigentlich. KMail kaputt? Muss ich mal verfolgen. Aber danke für den Hinweis.
Diesmal war es wieder OK.
Am Montag, 16. Juni 2003 11:05 schrieb mb@kuhtor.net:
[...] 3. Mit dem Array $_SESSION 4. Mit dem Array $HTTP_SESSION_VARS 5. Mit session_register() [...] 3.-5. sind allesamt ähnlich. Variablen werden linearisiert auf dem Server gespeichert, der Browser muss sich um nichts kümmern. Was mir nicht so ganz klar ist, wie werden die Sessions auseinandergehalten? Ich bin davon ausgegangen, dass php das Session Management übernimmt. Wenn ein Cookie nicht funktioniert, dann eben über $SESSID in $QUERY_STRING. Faslhc?
Im Prinzip richtig. Allerdings muss der Fallback auf den Querystring aktiv sein. (--enable-trans-sid beim Compilieren)
Jepp, ist aktiviert.
Mir ist der Wirkmechanismus der letzten drei überhaupt nicht klar. Mein Ergebnis war in etwa: $HTTP_SESSION_VARS funktioniert in Abhängigkeit vom Browser (Konqueror/Linux tut, Opera/Win32 tut, IE6 tut nicht, Mozilla/win32 tut nicht)
Seltsam. Sessions sollten eigentlich Browser-unabhängig sein, da sie serverseitig verwaltet werden. Der Browser sieht nur die Session-ID. Kann es sein, dass in den nicht funktionierenden Browsern Cookies ausgeschaltet sind? Dann hilft wohl
Nö, ist definitiv bei allen angewesen. Kann es sein, dass die Win-Browser kaputte Cookies zurückgeliefert haben?
Keine Ahnung. Kann ich mir aber irgendwie nicht vorstellen, das hätten schon mehr Leute gemerkt ;-)
29.4. Wie übergebe ich Session-IDs ohne Cookies an eine andere Seite? Was ist Fallback? http://www.dclp-faq.de/q/q-sessions-fallback.html
Fallback hätte eigentlich nicht nötig sein sollen, PHP-seitig war es aber aktiviert.
OK
$_SESSION funktioniert in Abhängigkeit des Betriebssystems (Konqueror/Linux tut, */Win32 tut nicht)
Meinst Du jetzt verschiedene PHP-Versionen oder greifst Du immer auf denselben Server zu (mit verschiedenen Clients)?
Sowohl als auch. PHP 4.2.2 von SuSE 8.1 und 4.0.6 von SuSE-7.weißichnich.
$_SESSION gibt es AFAIK erst ab PHP 4.1, ebenso wie $_GET und $_POST.
Ja, aber da hätte dann doch $HTTP_SESSION_VARS tun müssen. War aber nicht.
Das ist wohl auch nicht immer gesetzt ;-) php.net manual/configuration.html#ini.track-vars | track_vars boolean | | Wenn dieser Schalter aktiviert ist, werden GET-, POST- und | Cookie-Werte in den Umgebungsvariablen-Arrays $HTTP_GET_VARS, | $HTTP_POST_VARS und $HTTP_COOKIE_VARS abgelegt. Allerdings wundert mich gerade das folgende: php.net manual/ref.session.html | Anmerkung: Seit PHP 4.0.3 ist track_vars immer aktiviert. Bei 4.0.6 sollte es also an sein (oder meine Doku enthält einen Fehler, könnte ja auch sein.) Prüf es einfach kurz in der php.ini nach. Ansonsten teste es doch einfach mal unter beiden PHP-Versionen: <?php if (defined $HTTP_GET_VARS) {echo "GET_VARS ist definiert";} if (defined $HTTP_SESSION_VARS) {echo "SESSION_VARS ist definiert";} ?>
session_register() tut immer, unabhängig von Browser und Betriebssystem.
Dann nimm doch das *g*
Hab ich nun auch. Aber mir ist der Grund nicht klar, warum das funktioniert und der andere Kram nicht. Ich hatte mir Aufklärung über die Mechanismen dahinter erhofft.
Vielleicht findest Du ja oben den entscheidenden Hinweis ;-) Gruß Christian Boltz -- Yeah, Windows is great... I used it to download Linux.
Abend. Das Thema ist ja fast so ein Dauerbrenner wie das mit dem USB (-; Wenn ich mich recht erinnere (oder seit Ihr schon weiter gekommen?), dann ging es ursprünglich darum, dass das Session-Handling mit einem Linux-Rechner funktioniert hat mit diversenen Browsern unter Windows nicht. Das schliesst fuer mich erst mal ein PHP-seitiges Problem aus. Und da es mit mehreren Browser unter Windows auftritt, ist es wahrscheinlich auch nicht browserspezifisch. Wurde denn mal ausprobiert, ob es allgemein mit anderen Cookies, manuell mit setcookie() geschrieben, funktioniert? Und wenn nicht: Gehen sie auf dem Hinweg zum Browser verloren (Browser so einstellen, dass er bei Cookies zurueckfragt) oder auf dem Rueckweg? Gab es Versuche mit weiteren Systemen? Bye -- 1 Bodo Kaelberer 123 http://www.webkind.de/ 3 4 "A button I have made must be pushed." (ip)
Am Sonntag, 22. Juni 2003 03:25 schrieb Bodo Kaelberer:
Das Thema ist ja fast so ein Dauerbrenner wie das mit dem USB (-;
Argl, wenn es genauso unqualifiziert wird, sag bitte Bescheid, dann hör ich auf...
Das schliesst fuer mich erst mal ein PHP-seitiges Problem aus. Und da es mit mehreren Browser unter Windows auftritt, ist es wahrscheinlich auch nicht browserspezifisch.
Sondern Windowsspezifisch. Könnte ich als Antwort akzeptieren. Sollte mich aber schon wundern.
Wurde denn mal ausprobiert, ob es allgemein mit anderen Cookies, manuell mit setcookie() geschrieben, funktioniert?
Yepp. Funktionierte. Ausnahmslos überall.
Gab es Versuche mit weiteren Systemen?
Opera, IE6, Mozilla unter Win98, W2k, WinXP und Konqueror, Mozilla unter Linux. Völlig ratlos. Ds Problem ist mittlerweile aber erledigt. Wie geschrieben, session_register() tat, was verlangt war. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
Am Sonntag, 22. Juni 2003 01:29 schrieb Christian Boltz:
Am Samstag, 21. Juni 2003 01:48 schrieb Martin Borchert:
Am Samstag, 21. Juni 2003 01:18 schrieb Christian Boltz:
vorweg: würdest Du bitte Deinen Realname im Absender angeben? Ich weiß nämlich ganz gern, wem ich gerade helfe ;-) Hmmm... Steht doch drin... Eigentlich. KMail kaputt? Muss ich mal verfolgen. Aber danke für den Hinweis. Diesmal war es wieder OK.
Siehe Antwort auf David nebenan. :-}
$_SESSION funktioniert in Abhängigkeit des Betriebssystems (Konqueror/Linux tut, */Win32 tut nicht) Meinst Du jetzt verschiedene PHP-Versionen oder greifst Du immer auf denselben Server zu (mit verschiedenen Clients)? $_SESSION gibt es AFAIK erst ab PHP 4.1, ebenso wie $_GET und $_POST. Ja, aber da hätte dann doch $HTTP_SESSION_VARS tun müssen. War aber nicht. Das ist wohl auch nicht immer gesetzt ;-) Allerdings wundert mich gerade das folgende: php.net manual/ref.session.html | Anmerkung: Seit PHP 4.0.3 ist track_vars immer aktiviert. Bei 4.0.6 sollte es also an sein (oder meine Doku enthält einen Fehler, könnte ja auch sein.) Prüf es einfach kurz in der php.ini nach.
Ist an. Ich schließe in meinem Wahn Fehler in PHP und der Konfiguration auch weitgehend aus. Was einmal geht, sollte ja wohl immer gehen. Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
participants (6)
-
Bodo Kaelberer -
Christian Boltz -
David Haller -
Frank Röske -
Martin Borchert -
mb＠kuhtor.net