Server, Windows, oder Browser mit PHP Cookie/Session zerschossen

[Mike]

Hi,

ich weiss gar nicht wie ich so ein Durcheinander bei einem Problem schildern soll, aber ich versuchs mal.

Es war einmal, vor ungefähr 5 Stunden, alles im lokalen PHP Bereich wie erwartet. Das bedeutet ich konnte Cookies und Session setzen auslesen usw.

Es fing alles damit an, dass ich bei print_r($_COOKIE); alle Cookies vom Localhost zu sehen bekam, auch die von anderen(in anderen Verzeichnissen) als dem eigentlichen Script.

Nach einer dummen Aktion von mir, wo ich höchstens eine Fehlermeldung erwartet hatte, begann das Unglück seinen Lauf zu nehmen.

Was hatte ich getan?
Ich hatte die Sessionpfadangabe geändert: [ WARNUNG NICHT NACHMACHEN ]
++++++     ini_set('session.save_path','../sess/');   +++++++

Ich weiss ich hätte keinen relativen Pfad nehmen sollen, aber aus Bequemlichkeit und nur zum testen und weil keine gravierende Einsprüche da waren.... was solls. Wer rechnet denn auch mit so einem Ausmass...?

Was war passiert?
Jetzt wird es schwierig zu erklären. Ich sah auf einmal keine vorhanden Cookies von anderen Scripten mehr, die Session mit dem relativen Pfad allerdings funktionierte und auch genau dort wurden die Sessionfiles abgelegt.

Jetzt ist mein Sessionsystem aber so aufgebaut, dass in einem anderen Verzeichniss ein Script(welches ich nicht verändert hatte) erst mal beim Login ein Testcookie setzt, dieses konnte ich nun im Memberverzeichnis nicht mehr abrufen. Genausowenig alle anderen Cookies die vorher immer zu sehen waren.

Jetzt war mein erster Gedanke, vielleicht XAMPP zerschossen bzw. die set_cookie Funktion. Also habe ich die gleiche Version nochmals  installiert. Aber das Problem blieb.

Nun dachte ich vielleicht irgendwie den IE lädiert und mal das ganze mit FF
probiert. Ergebnis: Ähnliche Problematik und doch wieder ganz anders.

Ich habe eine identische Datei mit print_r($_COOKIE); einmal in das gleiche Verzeichnis gelegt wie die Datei die das Cookie setzt. Die andere im Parallelverzeichnis.

Parallelverzeichnis:

IE: Cookie Array()
FF: Cookie Array()

Verzeichnis wo Cookie gesetzt wird:

IE: Cookie Array()
FF: Array([checkc] => 1)

Also unterschiedliches Verhalten.
Da aber beide Browser nicht das zeigen wie vor 5 Stunden mit gleichen Scripten war, vermute ich mal es muss irgendwas an Windows kapputt gegangen sein, aber was?

Ich weiss auch gar nicht wie ich jetzt noch eine weitere Fehlersuche bewerkstelligen kann. Wäre also nett wenn mir jemand unter die Arme greift.

Danke
Mike

[Marcel Reiz]

Guten Morgen,

das ist ja grausam, was Dir da passiert ist. Häng dich jetzt bloß nicht auf vor lauter Verzweiflung!

ich empfehle Dir:
------------------
erstmal alles lesen:

Sessions:
http://de3.php.net/manual/en/book.session.php

Cookies:
http://de3.php.net/manual/en/function.setcookie.php

dann am Browser alle Header anzeigen lassen. Das geht beim Firefox mit der Live Headers Extension
https://addons.mozilla.org/de/firefox/addon/3829

und im Serverscriot auch alle Header anzeigen lassen die mit dem request kommen:
http://de3.php.net/manual/en/function.getallheaders.php

und die mit der Response abgeschickt werden:
http://de3.php.net/manual/en/function.apache-response-headers.php

wobei Du bei den beiden letzten Punkten natürlich aufpassen musst, dass erst alle Header gesetzt werden, also auch die Cookies, und dann erst die Anzeige stattfindet. Dazu hilft dir vielleicht auch die Funktion
http://de3.php.net/manual/en/function.ob-start.php

Wenn Du nun alle Pfade sortiert hast zu den Ressourcen, daran gedacht hast, dass für ein ordnungsgemäßes Cookie-Handling immer mindestens ein Pinkt in der URL sein muss (!), dann solltest Du das Handling bald verstanden haben.

Das alles wird sich nicht in Deinem Originalskript ausprobieren lassen, sondern nur in extra dafür gemachten Test Testskripten. Da darfst Du nicht zu faul sein! Ach ja und noch was:

Error_reporting(E_ALL);
ini_set(display_errors, true);

gehören an den Anfang jedes Testskriptes.

Viel Spaß beim Experimentiern

Marcel

[Mike]

Hi Marcel,

dann am Browser alle Header anzeigen lassen. Das geht beim Firefox mit der Live Headers Extension
https://addons.mozilla.org/de/firefox/addon/3829

das war noch das einzig nützliche aus deiner Antwort und

Wenn Du nun alle Pfade sortiert hast zu den Ressourcen, daran gedacht hast, dass für ein ordnungsgemäßes Cookie-Handling immer mindestens ein Pinkt in der URL sein muss (!), dann solltest Du das Handling bald verstanden haben.

wie so das sein soll verstehe ich nicht, denn localhost hat natürlich keinen Punkt, aber dennoch funktionierten in der Vergangenheit alle Cookiescripte tadellos. Tatsächlich ist es aber auch so, dass ich noch (vor Jahren, weiss gar nicht mehr wie das ging, irgendeine Datei im Windowsordner editiert)einen Domainnamen im Windows angelegt, den ich aber sehr selten nutze. Wie auch immer ob localhost oder Domain, das Problem ist das Gleiche.

------------------------------------------------

Stand der Dinge:
Irgendetwas ist kapputt gegangen mit der Pfadangabe und den Rechten.
Und das kann letztendlich nur Windows betreffen, kein Server kein Browser.

Ich kann das Problem mit 3 Dateien die ich auf minimalistische reduziert habe, darstellen.

Verezeichnis: a darin verzeichnis a1

In a liegt eine kleine PHP Datei nennet sich sinnigerweise "showcook.php" die nur das enthält:

<?php print_r($_COOKIE); ?>

In a1 liegen 2 Dateien eine heisst "cook.php" und die andere "cook2.php"

cook.php:

<?php  
  
if($_COOKIE['countx']){$x = ($_COOKIE['countx']*1)+1;}else{$x=1;}  
  
setcookie('countx',$x,0,'/');  
  
print_r($_COOKIE);  
 ?>

cook2.php:

<?php  
if($_COOKIE['countmore']){$x = ($_COOKIE['countmore']*1)+1;}else{$x=1;}  
setcookie('countmore',$x);  
  
print_r($_COOKIE);  
 ?>

----------------------------------

Der wesentlich Unterschied ist die optionale Pfadangebe bei set_cookie.

Diese war lokal bisher nie von Nöten, jetzt schon!!!

----------------------------------
Aber es kommt noch schlimmer:

Wenn ich nun die cook und cook2 ein paar mal refreshed habe hat sich der Counter logischerweise erhöht und die Cookies sind natürlich vorhanden.

Sind sie? Nicht wirklich, zumindest nicht wie es vorher war.

Rufe ich nun showcook im FF auf erhalte ich Array ( [countx] => 6 ) ,
was bedeutet FF zeigt mir nur den Cookie an, der mit der optionalen Pfadangabe gesetzt wurde.

Beim Aufruf von cook und cook2, die ja beide im selben Verzeichnis liegen, lasse ich ja auch die Cookies anzeigen, dort werden beide auf beiden Datien angezeigt.

Jetzt kommt aber auch noch der IE hinzu:
Der zeigt mir, nicht mal wie FF, ein einziges Cookie auf showcook an:
Array ( ) . cook und cook2 dort schon aber nicht unbedingt verlässlich. Will sagen, er zeigt zumindest diese beiden Dateien nur so an wie FF, wenn ich mindestens cook.php also mit Pfad aktiviert hatte, dann  zeigt er beide wenn ich danach auch cook 2 besucht hatte. Zuerst cooks ein paar mal refreshed kommt nichts.

----------------------------------------------

Die Headerausgabe im FF bei der cook.php:

#################################################
http://localhost/test/a/a1/cook.php

GET /test/a/a1/cook.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: countmore=3; countx=5
Cache-Control: max-age=0

HTTP/1.x 200 OK
Date: Sun, 19 Apr 2009 15:39:26 GMT
Server: Apache/2.2.9 (Win32) DAV/2 mod_ssl/2.2.9 OpenSSL/0.9.8h mod_autoindex_color PHP/5.2.6
X-Powered-By: PHP/5.2.6
Set-Cookie: countx=6; path=/
Content-Length: 49
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

########################################

bei der cook2.php:

##############################

http://localhost/test/a/a1/cook2.php

GET /test/a/a1/cook2.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: countmore=3; countx=6
Cache-Control: max-age=0

HTTP/1.x 200 OK
Date: Sun, 19 Apr 2009 15:42:23 GMT
Server: Apache/2.2.9 (Win32) DAV/2 mod_ssl/2.2.9 OpenSSL/0.9.8h mod_autoindex_color PHP/5.2.6
X-Powered-By: PHP/5.2.6
Set-Cookie: countmore=4
Content-Length: 49
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

##############################

bei der showcook.php:

##########################################
http://localhost/test/a/showcook.php

GET /test/a/showcook.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: countx=6
Cache-Control: max-age=0

HTTP/1.x 200 OK
Date: Sun, 19 Apr 2009 15:44:33 GMT
Server: Apache/2.2.9 (Win32) DAV/2 mod_ssl/2.2.9 OpenSSL/0.9.8h mod_autoindex_color PHP/5.2.6
X-Powered-By: PHP/5.2.6
Content-Length: 28
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

##########################################

Das Riesenproblem dabei ist natürlich auch noch, dass nun sehr viele Scripte(auch Fremdscripte) nicht mehr laufen. Denn in der Regel werden dort bei Cookie angaben nicht die Optionalen Parameter genutzt.

Es steht aber für mich nun ausser Zweifel, dass etwas im Windows kapputt ist. Ich frage mich wie sich sowas auf einem Windowsserver im Netz auswirken könnte, aber egal ist ja jetzt nicht das Thema.

Wo muss bei Windos ansetzen um den Fehler zu finden?

Mike

[Mike]

Nachtrag:

Jetzt kommt aber auch noch der IE hinzu:
Der zeigt mir, nicht mal wie FF, ein einziges Cookie auf showcook an:
Array ( ) . cook und cook2 dort schon aber nicht unbedingt verlässlich. Will sagen, er zeigt zumindest diese beiden Dateien nur so an wie FF, wenn ich mindestens cook.php also mit Pfad aktiviert hatte, dann  zeigt er beide wenn ich danach auch cook 2 besucht hatte. Zuerst cooks ein paar mal refreshed kommt nichts.

Mit nicht zuuverlässig, meine ich auch wenn ich den Browser schliesse und dann wieder die Seiten öffne kann das Verhalten wieder komplett anders sein.

So zeigt aktuell nur die Datei die Cookies an die sie auch gesetzt hat, also cook.php seine und cook2.php auch nur seine, showcook.php gar keine.

Dieses wechselnde Verhalten kann doch nur beudeuten das Windows irgendwie versucht die Pfadangebe zu interpretieren aber dann zu unberechenbaren Ergebnissen kommt. Aber wie gesagt, IE macht es unverlässlich und FF macht es verlässlich aber auch nicht richtig.

Mike

[ChrisB]

Hi,

Mit nicht zuuverlässig, meine ich auch wenn ich den Browser schliesse und dann wieder die Seiten öffne kann das Verhalten wieder komplett anders sein.

Dann geht es wieder von vorne los, es sind erst mal keine Cookies vorhanden - schliesslich hast du einmal als expires 0 angegeben, und das andere mal gar keine Angabe gemacht - was laut Manual beides auf genau eins hinausläuft, nämlich dass die Cookies nur für die Dauer der Surf-Sitzung gültig sind, also nach dem Schliessen des Browsers verfallen sollen.

So zeigt aktuell nur die Datei die Cookies an die sie auch gesetzt hat, also cook.php seine und cook2.php auch nur seine, showcook.php gar keine.

Beim jeweils ersten Aufruf nach dem Neustart des Browsers - oder auch bei nachfolgenden?

Dieses wechselnde Verhalten kann doch nur beudeuten das Windows irgendwie versucht die Pfadangebe zu interpretieren aber dann zu unberechenbaren Ergebnissen kommt.

Nein, Nei-en, Nei-ei-en.
Lass jetzt bitte endlich "Windows" aus dem Spiel.

Aber wie gesagt, IE macht es unverlässlich und FF macht es verlässlich aber auch nicht richtig.

FF macht es, nach deiner bisherigen Beschreibung, durchaus richtig - nur dein Verständnis von "richtig" ist in Bezug auf Cookies noch nicht *richtig*.

Und zum IE, wie gesagt - von dem sind Probleme bekannt, insb. beim lokalen Testen über localhost.

MfG ChrisB

[ChrisB]

Hi,

Verezeichnis: a darin verzeichnis a1

In a liegt eine kleine PHP Datei nennet sich sinnigerweise "showcook.php" die nur das enthält:

In a1 liegen 2 Dateien eine heisst "cook.php" und die andere "cook2.php"

Also, du hast also folgende Script-URLs:
http://localhost/a/showcook.php
http://localhost/a/a1/cook.php
http://localhost/a/a1/cook2.php

Wenn cook.php seinen Cookie mit der Pfandangabe / setzt, dann ist dieser Cookie überall unter der Domainwurzel verfügbar - also kann auch /a/showcook.php diesen "sehen" (d.h. bekommt ihn beim Request mitgesendet).

Wenn cook2.php einen Cookie ohne Pfadangabe setzt, dann ist dieser Cookie nur unterhalb des aktuellen Pfades, in dem dieses Script liegt, gültig, also unterhalb von /a/a1/.
Dass /a/showcook.php diesen Cookie nicht "sehen" kann, ist ganz richtig - muss so sein.

Works as designed bis hier her.

Der wesentlich Unterschied ist die optionale Pfadangebe bei set_cookie.

Diese war lokal bisher nie von Nöten, jetzt schon!!!

Dann hattest du lokal bisher entweder immer "flache" Verzeichnisstrukturen, in denen das nicht auffiel, oder du hast sonst irgendwas anders gemacht.

Wenn ich nun die cook und cook2 ein paar mal refreshed habe hat sich der Counter logischerweise erhöht und die Cookies sind natürlich vorhanden.

Sind sie? Nicht wirklich, zumindest nicht wie es vorher war.

Rufe ich nun showcook im FF auf erhalte ich Array ( [countx] => 6 ) ,
was bedeutet FF zeigt mir nur den Cookie an, der mit der optionalen Pfadangabe gesetzt wurde.

Jaseufzsieheoben: Works as designed und *muss* *so* *sein*.

Beim Aufruf von cook und cook2, die ja beide im selben Verzeichnis liegen, lasse ich ja auch die Cookies anzeigen, dort werden beide auf beiden Datien angezeigt.

Natürlich - beide Dateien liegen innerhalb eines Pfades, für den beide Cookies gültig sind.

Jetzt kommt aber auch noch der IE hinzu:

Insb. der ist bekannt dafür, teilweise Probleme zu bereiten, wenn der verwendete Domainname nicht in "ausreichender" Anzahl Punkte enthält. (Weitere dazu in den Nutzerkommentaren zu setcookie.)

Der zeigt mir, nicht mal wie FF, ein einziges Cookie auf showcook an:
Array ( ) . cook und cook2 dort schon aber nicht unbedingt verlässlich. Will sagen, er zeigt zumindest diese beiden Dateien nur so an wie FF, wenn ich mindestens cook.php also mit Pfad aktiviert hatte, dann  zeigt er beide wenn ich danach auch cook 2 besucht hatte. Zuerst cooks ein paar mal refreshed kommt nichts.

Die Beschreibung ist mir zu vage, um dazu eine definitische Aussage zu treffen - aber wie gesagt, Probleme mit dem IE sind unter gewissen Umständen bekannt.

Das Riesenproblem dabei ist natürlich auch noch, dass nun sehr viele Scripte(auch Fremdscripte) nicht mehr laufen. Denn in der Regel werden dort bei Cookie angaben nicht die Optionalen Parameter genutzt.

Müssen ja auch nicht; es gibt genügend Anwendungsfälle, in denen das innerhalb bestimmter Pfadstrukturen auch so wie gewünscht funktioniert.

Es steht aber für mich nun ausser Zweifel, dass etwas im Windows kapputt ist.

Halte ich nach wie vor für eine ziemlich unsinnige Vermutung.
(Wohin gegen ich die, dass du von den Vorgängen und Zusammenhängen bisher nur wenig Ahnung hast/hattest, aufrecht erhalte.)

Wo muss bei Windos ansetzen um den Fehler zu finden?

Setze damit an, dass du nicht bei Windows ansetzt.

Was höchstens noch von Interesse sein könnte, sind deine Einstellungen in den jeweiligen Testbrowsern bzgl. der Behandlung von Cookies - über die hast du uns bisher noch nichts mitgeteilt. (Aber auch die wären kein Windows-spezifisches Problem.)

MfG ChrisB

[Mike]

Hi,

Wenn cook2.php einen Cookie ohne Pfadangabe setzt, dann ist dieser Cookie nur unterhalb des aktuellen Pfades, in dem dieses Script liegt, gültig, also unterhalb von /a/a1/.
Dass /a/showcook.php diesen Cookie nicht "sehen" kann, ist ganz richtig - muss so sein.

dann stellt sich immer noch dir Frage warum das vorher anders war, aber da mag ich einen bereits bestehenden Fehler im IE zustimmen.

Aber, wie schon geschildert, kann ich auch aktuell im verz. a1 mit cook2.php nicht den cookie von cook2.php sehen. Und natürlich, versuche mich nicht immer als DAU darzustellen, habe ich die Seiten, wie auch vorher beschrieben, ein paar mal refreshed und den Wert zu erhöhen.

Wenn du wirklich glaubst nach allem was ich hier so schreibe wüsste ich nicht, dass ein Cookie erst beim erneuten Aufruf abgefragt werden kann, dann solltest du dein Einschätzungvermögen mal überdenken.

Aber viele Posts von dir, nicht nur hier, enthalten seht oft die Unterstellung der Fragende hat keine Ahnung, widerlegt man dich dann gibts nur ein, woher soll ich deinen Wissenstand kennen, blabla...

So wie auch immer, es sieht dann also so aus als wenn IE defekt ist, und vermutlich auch schon länger war. Das deckkt sich mit einer anderen Frage die ich hier vor Jahren mal stellte, wegen seltsamen Verhaltens in Bezug auf Verlauf, das damals und bis heute nicht zu lösen war.

Ich werde das nachher mit einem IE-Browservergleich testen.

2 Dinge die mich aber doch wundern wenn sich der Browser als defekt herausstellen wird.

1. Warum kann eine simple Pfadänderung der Session in PHP so eine Auswirkung auf den Browser haben. Na ja erst mal nebensächlich.

2. Das bedeutet in all den Jahren als ich mich ein wenig darüber geärgert hatte, dass bei meinen Cookie Prüfungen ich immer auch noch die parallel laufenden Cookies von Scripten in weit entferneten Verzeichnissen sehen konnte, welche eben ohne Pfad gesetzt wurden, häte mir schon auffallen müssen, da stimmt etwas nicht.

Mike

[ChrisB]

Hi,

Aber, wie schon geschildert, kann ich auch aktuell im verz. a1 mit cook2.php nicht den cookie von cook2.php sehen.

Dann untersuche die Header noch mal - und zwar in einem Falle, wo du dieses Fehlverhalten feststellst und nicht erst "hinterher" oder davon unabhängig.

Und natürlich, versuche mich nicht immer als DAU darzustellen,

Sorry, aber das machst du hier bisher zum Grossteil selber.

Wenn du wirklich glaubst nach allem was ich hier so schreibe wüsste ich nicht, dass ein Cookie erst beim erneuten Aufruf abgefragt werden kann, dann solltest du dein Einschätzungvermögen mal überdenken.

Habe ich das behauptet?

Aber viele Posts von dir, nicht nur hier, enthalten seht oft die Unterstellung der Fragende hat keine Ahnung, widerlegt man dich dann gibts nur ein, woher soll ich deinen Wissenstand kennen, blabla...

Zumindest was das Verhalten bzgl. der Pfadangabe angeht, kann man glaube ich guten Gewissens behaupten, dass du darüber nicht Bescheid wusstest - sonst hätte ich es dir ja nicht erst erklären müssen.

2 Dinge die mich aber doch wundern wenn sich der Browser als defekt herausstellen wird.

1. Warum kann eine simple Pfadänderung der Session in PHP so eine Auswirkung auf den Browser haben. Na ja erst mal nebensächlich.

Du nimmst immer noch an, dass das der Fall wäre - einen gesicherten Beleg für diese (m.E. mehr als abenteuerliche) Vermutung hast du noch nicht erbringen können.

Vielleicht hast du, also irgendeine Nachfrage bzgl. eines "ungewöhnlichen" Cookies seitens deines Browsers kam, irgendeine Einstellung getätigt, die sich auch jetzt auf davon unabhängige Cookies auswirkt ...?
(Ja, auch das ist nur eine reine Vermutung - aber zu den Einstellungen bzgl. Cookiebehandlung hast du ja immer noch nichts verlauten lassen, also ist mehr als das auch nicht drin.)

2. Das bedeutet in all den Jahren als ich mich ein wenig darüber geärgert hatte, dass bei meinen Cookie Prüfungen ich immer auch noch die parallel laufenden Cookies von Scripten in weit entferneten Verzeichnissen sehen konnte, welche eben ohne Pfad gesetzt wurden, häte mir schon auffallen müssen, da stimmt etwas nicht.

So viel zum Thema Kenntnis der Materie also.

MfG ChrisB

[Mike]

Hi,

»» Aber, wie schon geschildert, kann ich auch aktuell im verz. a1 mit cook2.php nicht den cookie von cook2.php sehen.

Dann untersuche die Header noch mal - und zwar in einem Falle, wo du dieses Fehlverhalten feststellst und nicht erst "hinterher" oder davon unabhängig.

cook.php

------ HEADER -------
Array
(
    [Accept] => */*
    [Accept-Language] => de
    [Accept-Encoding] => gzip, deflate
    [User-Agent] => Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; FDM)
    [Host] => localhost
    [Connection] => Keep-Alive
    [Cookie] => countx=20
)

------ Response HEADER -------
Array
(
    [X-Powered-By] => PHP/5.2.6
    [Set-Cookie] => countx=21; path=/
)

################################

cook2.php

------ HEADER -------
Array
(
    [Accept] => */*
    [Accept-Language] => de
    [Accept-Encoding] => gzip, deflate
    [User-Agent] => Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; FDM)
    [Host] => localhost
    [Connection] => Keep-Alive
    [Cookie] => countmore=22
)

------ Response HEADER -------
Array
(
    [X-Powered-By] => PHP/5.2.6
    [Set-Cookie] => countmore=23
)

// Resultat: beide im gleichen Verzeichnis, eine setzt cookie mit pfad eine ohne. Aber beide können nicht den Cookie des anderen anzeigen.

»» Und natürlich, versuche mich nicht immer als DAU darzustellen,

Sorry, aber das machst du hier bisher zum Grossteil selber.

Nur weil ich nicht alles weiss, wer kann das schon von sich behaupten, macht mich das nicht zum DAU.

»» Wenn du wirklich glaubst nach allem was ich hier so schreibe wüsste ich nicht, dass ein Cookie erst beim erneuten Aufruf abgefragt werden kann, dann solltest du dein Einschätzungvermögen mal überdenken.

Habe ich das behauptet?

so habe ich das:

Beim jeweils ersten Aufruf nach dem Neustart des Browsers - oder auch bei nachfolgenden?

verstanden.

Vielleicht hast du, also irgendeine Nachfrage bzgl. eines "ungewöhnlichen" Cookies seitens deines Browsers kam, irgendeine Einstellung getätigt, die sich auch jetzt auf davon unabhängige Cookies auswirkt ...?

Du kannst davon ausgehen, dass meinerseits nirgendwo eine Änderung stattgefunden ausser der kurzfristigen Pfadänderung des Session.

Ob ich auf Anfrage des Browsers etwas akzeptiert oder nicht akzeptiert hätte, ist wieder eine DAU anspielung, denn wenn es passiert wäre wüsste ich das sehr wohl im meinen Überlegungen einzubringen.Glaube ich;-)

(Ja, auch das ist nur eine reine Vermutung - aber zu den Einstellungen bzgl. Cookiebehandlung hast du ja immer noch nichts verlauten lassen, also ist mehr als das auch nicht drin.)

Was soll ich dazu auch verlauten lassen, wenn sich da nicht geändert. Es geht hier um Verhalten:Vorher  => Verhalten:Hinterher

Aber wenn du meinst es würde etwas aussagen:

Cookies akzeptieren: Ja
Sitzungscookie zulassen: Ja immer
Cookies von Drittanbietern: Nein

»» 2. Das bedeutet in all den Jahren als ich mich ein wenig darüber geärgert hatte, dass bei meinen Cookie Prüfungen ich immer auch noch die parallel laufenden Cookies von Scripten in weit entferneten Verzeichnissen sehen konnte, welche eben ohne Pfad gesetzt wurden, häte mir schon auffallen müssen, da stimmt etwas nicht.

So viel zum Thema Kenntnis der Materie also.

Wie bereits gesagt, dass nicht zu wissen macht mich nicht zum DAU. Ich bin überzeugt du wie auch die meissten anderen nutzen seit Jahren in irgendwelchen Scripten Sachen die fehlerhaft sind aber das gewünschte Resultat bringen und daher nicht auffallen.

Selbst im Manual sind genügend solcher Beispiele zu finden.

############################################

Nun zm Punkt. Es ist der Browser IE. Auf einem anderen Rechner mit identischem IE6 tritt das Problem nicht auf. Die Frage ist nur, so wie
der IE mit dem OS verbunden, können natürlich eine Menge Einstellungen im System irgendwo liegen und wenn ich nun den IE6 neu aufspielen würde, hätte ich vermutlich immer noch das gleiche Problem.

Zumindest war das so bei der bereits angedeuteten Verlaufsproblematik, da hatte ich auch von 5.5 auf 6 upgedatet aber das Problem blieb.

Was ich nun bräuchte wäre etwas um den IE restlos zu entfernen um Ihn dann neu zu installieren. Wie mache ich das?

Und, ist das die richtige Downloadadresse für mich, denn es wird ja dort auch noch auf international verwiesen, aber dort finde ich nichts?

Mike

[Tom]

Hello,

[...]

und hast Du nun schon mal den Rat befolgt und Dir eine Testdomain eingerichet, die z.B. "testserver.lan" heißt? Das ist auch mit einem lokalen Apachen aus dem Xampp-Paket möglich. Ist immer das erste, was ich mache, mir auf die IPs 127.0.0.1, 127.0.0.2, usw. ein paar virtuelle Hosts zu legen.

Übrigens hab ich das damals auch nicht glauben wollen, als mir Sven Rautenberg die damals noch relativ unbekannte Tatsache mit mindestens zwei Abschnitten (Periods) in der Domain unter die Nase gerieben hat.

Seitdem habe ich mit den Testscripten keinerlei Cookie-Probleme mehr, egal welchen Browser ich bisher benutzt habe.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Mike]

Hi,

ja wie gesagt hatte ich das schon vor langer Zeit gemacht. Ich weiss aber gar nicht mehr wie. Ich weiss nur in irgendeinem Forum, vielleicht hier, eine Anleitung dafür gefunden zu haben.

Aber das hatte nichts mit dem Server zu tun, sondern war eine Datei im Windowsverezichnis und somit wesentlich pflegeleichter bei wechselnden Xampp zu handhaben. Vielleicht weiss jemand welche Datei bei windows das ist.

Auf jeden fall kann ich also seit Jahren anstatt localhost auch test.de eingeben und komme auf meinen Server anstatt Stiftung Warentest.

Aber dieses Domain habe ich fast nie genutzt und dennoch nie Probleme bei Session oder Cookies oder beides mit localhost. Dachte ich zumindest, denn nun weiss ich ja, dass meine Scripte viel mehr sehen konnten von anderen Scripten als erlaubt.

Mike

[Tom]

Hello,

das war noch das einzig nützliche aus deiner Antwort und

vermutlich, weil Du zu faul bist, den Rest zu verstehen und durchzuarbeiten?

Wenn Du nun alle Pfade sortiert hast zu den Ressourcen, daran gedacht hast, dass für ein ordnungsgemäßes Cookie-Handling immer mindestens ein Pinkt in der URL sein muss (!), dann solltest Du das Handling bald verstanden haben.

wie so das sein soll verstehe ich nicht, denn localhost hat natürlich keinen Punkt, aber dennoch funktionierten in der Vergangenheit alle Cookiescripte tadellos. Tatsächlich ist es aber auch so, dass ich noch (vor Jahren, weiss gar nicht mehr wie das ging, irgendeine Datei im Windowsordner editiert)einen Domainnamen im Windows angelegt, den ich aber sehr selten nutze. Wie auch immer ob localhost oder Domain, das Problem ist das Gleiche.

weil das mal so festgelegt wurde:
http://curl.haxx.se/rfc/cookie_spec.html

siehe Abschnitt  "domain=DOMAIN_NAME"

[
Only hosts within the specified domain can set a cookie for a domain and domains must have at least two (2) or three (3) periods in them to prevent domains of the form: ".com", ".edu", and "va.us". Any domain that fails within one of the seven special top level domains listed below only require two periods. Any other domain requires at least three. The seven special top level domains are: "COM", "EDU", "NET", "ORG", "GOV", "MIL", and "INT".
]

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[ChrisB]

Hi,

ich weiss gar nicht wie ich so ein Durcheinander bei einem Problem schildern soll, aber ich versuchs mal.

Wenn du es etwas weniger durcheinander schildern würdest, wäre vermutlich schon viel gewonnen ...

Was hatte ich getan?
Ich hatte die Sessionpfadangabe geändert: [ WARNUNG NICHT NACHMACHEN ]
++++++     ini_set('session.save_path','../sess/');   +++++++

Schön, damit liegt das Temp-Verzeichnis für Session-Daten jetzt irgendwo anders.
Wo? Das wirst du ja wohl wenigstens an Hand deiner Verzeichnisstruktur ermittelt und überprüft haben.

Da aber beide Browser nicht das zeigen wie vor 5 Stunden mit gleichen Scripten war, vermute ich mal es muss irgendwas an Windows kapputt gegangen sein, aber was?

Wenn das Temp-Verzeichnis wirklich irgendwo angelegt worden wäre, wo es das eher nicht sollte - dann sehe ich immer noch nicht, was dadurch wirklich "kaputt" gehen sollte. Selbst wenn im dortigen Pfad bereits ein Verzeichnis namens "sess" existiert hätte, hätte das bestehen bleiben sollen. Und vorhandene Dateien darin auch, sofern ihre Namen nicht gerade mit den eher kryptischen, die PHP für Session-Dateien vergibt, kollidieren.

Und mit Cookies kann man eigentlich auch kaum etwas wirklich "kaputt" machen. Entweder akzeptiert der Client die, oder nicht. Aber dass die im Dateisystem des Clients Unheil anrichten, halte ich bei heutigen Browsern für nahezu ausgeschlossen.

Die Caches deiner Testbrowser hast du aber schon gelöscht (und auch "gründlich"), oder?

Deine Wild ins Kraut schiessenden Vermutungen, welche Katastrophe sich ereignet haben könnte, lassen vermuten, dass du nicht allzu viel Ahnung und Kenntnisse von den Vorgängen bzgl. Cookies und PHP-Sessions hast - vielleicht solltest du dich diesbezüglich erst mal ein bisschen schlau(er) machen (Marcel hat dazu ja auch schon ein paar Links gepostet).

Ich vermute jedenfalls, dass sich das ganze letztendlich als weit weniger "dramatisch" erweisen wird, als du es hier dargestellt hast ...

MfG ChrisB

[Mike]

Hi,

Schön, damit liegt das Temp-Verzeichnis für Session-Daten jetzt irgendwo anders.
Wo? Das wirst du ja wohl wenigstens an Hand deiner Verzeichnisstruktur ermittelt und überprüft haben.

ja, und hat auch gar nichts mehr damit zu tun. Das war der Auslöser und trotz der Problematik, funkioniert das. Will sagen, der Pfad wurde genutzt, die Session dort abgelegt.

Aber zur Fehlersuche benutze ich jetzt gar keine Session mehr, weil es eher ein CookieProblem ist, was aber durch die Pfadänderung enstanden ist.

Somit gibt es jetzt keine INI-Veränderungen oder sonstwas mehr.

Wenn das Temp-Verzeichnis wirklich irgendwo angelegt worden wäre, wo es das eher nicht sollte - dann sehe ich immer noch nicht, was dadurch wirklich "kaputt" gehen sollte.
Und mit Cookies kann man eigentlich auch kaum etwas wirklich "kaputt" machen. Entweder akzeptiert der Client die, oder nicht. Aber dass die im Dateisystem des Clients Unheil anrichten, halte ich bei heutigen Browsern für nahezu ausgeschlossen.

Wenn du das denkst kannst du ja mal gerne meine Warnung missachten und das ausprobieren. Ich hätte das vorher auch für unmöglich gehalten.

Die Caches deiner Testbrowser hast du aber schon gelöscht (und auch "gründlich"), oder?

Darauf kannst du wetten.

Ich vermute jedenfalls, dass sich das ganze letztendlich als weit weniger "dramatisch" erweisen wird, als du es hier dargestellt hast ...

Schön wärs aber leider nein. Weitere Einzelheiten bereite ich gerade vor als Antwort auf Marcel.

Mike

[Mike]

Hi,

da keine Lösung in Aussicht schien habe ich nun den IE8 installiert.
(Übrigens das Forum hier ist damit nur im Kompalibilitätsmodus ansehnlich)

Das passt mir zwar gar nicht, aber was soll ich machen...

Tatsache ist, die Cookies werden nun so abgehandelt wie im FF. Immer noch rätselhaft, dass eine anscheinend harmlos anzumutende PHP Sache solch einen Schaden verursachen kann, aber ok der IE war wohl auch schon teillädiert, nun eben komplett.

Dennoch benötige ich dringend für meine Arbeit eine Möglichkeit, den IE6 zu nutzen. Dabei reicht es mir nicht für jede Änderung das an einem anderen PC zu betrachten. Was kann ich machen?

1. Komplett Windows neu zu installieren eben wieder mit IE6
Nicht wirklich erstrebenswert.

2. Eine Multibrowser Umgebung zu installieren, aber ob die Anbieter davon das wirklich alles im Griff haben?

3. Vielleicht eine Lösung von euch?

Gruss
Mike

[Dennis]

Hi Mike,

da keine Lösung in Aussicht schien habe ich nun den IE8 installiert.
(Übrigens das Forum hier ist damit nur im Kompalibilitätsmodus ansehnlich)

Mit Verlaub, ich kann im IE 8 keinen wesentlichen Unterschied feststellen, was die Darstellung dieses Forums im Kompatibilitätsmodus und im Standardmodus anbelangt. Im Standardmodus ist der Abstand zwischen zwei Threads etwas größer, zu groß meines Erachtens. Betriebssystem ist Windows Vista 64bit, Internet Explorer 8.0.6001 32bit, bei der 64bit Version des IEs siehts aber genauso aus.

Viele Grüße,
  ~ Dennis.

[Mike]

Hi Dennis,

Mit Verlaub, ich kann im IE 8 keinen wesentlichen Unterschied feststellen, was die Darstellung dieses Forums im Kompatibilitätsmodus und im Standardmodus anbelangt. Im Standardmodus ist der Abstand zwischen zwei Threads etwas größer, zu groß meines Erachtens.

dann muss man das wohl unter Geschmackssache sehen. Ich persönlich finde die Abstände im normalen IE8-Modus viel zu gering. Die einzelnen Posts lassen sich nicht mehr exakt anklicken, man kommt zu schnell in einen anderen Post und die einzelnen Threads erscheinen fast als Einer.

Mike