PHP, HTTP Cookie vom Client erfragen
Thomas Schmieder
- https
Hallo,
funktioniert die Archiv-Suche nicht mehr, oder bin ich zu blöd?
Wie kann ich in einem PHP-Script erfragen, ob ein eben gesetzter Cookie auf dem Client auch angenommen wurde? Das Script soll nicht enden zwischendurch.
In der Sessionverwaltung ist ja scheinbar auch so ein Mechanismus eingebaut. Anderenfalls könnte PHP ja keinen automatischen Fallback machen.
Also nochmal zur Verdeutlichung:
1. Client ruft Script auf
2. Server sendet HTTP-Header mit Cookie-Anweisung
3. Server sendet HTTP-Heder mit ????? getCookie
4. Client sendet Cookie zurück
5. Server wertet aus und sendet das HTTÜ-Attachement.
Und gut is...
Ich habe versucht, das durch Studium der HTTP-Specs selber rauszufinden. Komme da aber leider nicht weiter.
Liebe Grüße aus http://www.braunschweig.de
Tom
Hallihallohallöle!
funktioniert die Archiv-Suche nicht mehr, oder bin ich zu blöd?
Ist das "oder" in Deiner Aussage ein exklusives oder ein inklusives "oder"?
Der Joker
Hi,
funktioniert die Archiv-Suche nicht mehr, oder bin ich zu blöd?
Ist das "oder" in Deiner Aussage ein exklusives oder ein inklusives "oder"?
suchs Dir aus. Ich vertrag das schon.
Tom
Hi Tom,
funktioniert die Archiv-Suche nicht mehr, oder bin ich zu blöd?
Ist das "oder" in Deiner Aussage ein exklusives oder ein inklusives "oder"?
suchs Dir aus. Ich vertrag das schon.
ist doch auch egal. das erste ist IMHO true und das zweite nicht. ob zwangsläufig inklusiv oder nicht ist da egal, der freundliche[tm] ausdruck da wird true zurückgeben, eben weil die suche kaputt ist.
Und ist die syntax in der deutschen sprache nicht so angelegt, dass ein ausdruck bereits wahr wird, wenn nur eine inklusive bedingung zutrifft? *scnr*
Tom
Fabian
Hi,
funktioniert die Archiv-Suche nicht mehr, oder bin ich zu blöd?
Ist das "oder" in Deiner Aussage ein exklusives oder ein inklusives "oder"?
suchs Dir aus. Ich vertrag das schon.
ist doch auch egal. das erste ist IMHO true und das zweite nicht. ob zwangsläufig inklusiv oder nicht ist da egal, der freundliche[tm] ausdruck da wird true zurückgeben, eben weil die suche kaputt ist.
Bei einem exklusiven Oder kommt aber nur dann true raus, wenn genau eines der beiden Teile true ist.
Sind beide wahr, ergibt XOR false!
Und ist die syntax in der deutschen sprache nicht so angelegt, dass ein ausdruck bereits wahr wird, wenn nur eine inklusive bedingung zutrifft? *scnr*
Das wäre dann ein shortcut operator. Das hat aber nichts mit OR/XOR zu tun.
Der Joker
Guten Morgen,
lange nix mehr von dir gehört (wenn man 3 Tage als lang klassifiziert) ;-))
funktioniert die Archiv-Suche nicht mehr, oder bin ich zu blöd?
nein, sie geht nicht.
Wie kann ich in einem PHP-Script erfragen, ob ein eben gesetzter Cookie auf dem Client auch angenommen wurde? Das Script soll nicht enden zwischendurch.
$_COOKIE['$var']
(bin ich gestern dran verzweifelt, weil ich meine HP auf Register_Globals=off umgestellt hab.)
In der Sessionverwaltung ist ja scheinbar auch so ein Mechanismus eingebaut. Anderenfalls könnte PHP ja keinen automatischen Fallback machen.
Also nochmal zur Verdeutlichung:
- Client ruft Script auf
- Server sendet HTTP-Header mit Cookie-Anweisung
setcookie(..); //soweit logisch
- Server sendet HTTP-Heder mit ????? getCookie
wenn noch nix anderes ausgegeben ist, wie du weist.
- Client sendet Cookie zurück
mhh, eigentlich sendet er nur Cookie_accepted oder eben nicht.
- Server wertet aus und sendet das HTTÜ-Attachement.
welches attachment? in dem moment wo bei 4. ein accepted gesendet wird steht das cookie in $_COOKIE[] zur verfügung. was möchtest du sonst?
Liebe Grüße aus http://www.braunschweig.de
Tom
Fabian
Hi Fabian,
lange nix mehr von dir gehört
Du hier und nicht in der Schule?
Ich war ein bisschen angeschlagen die letzten Tage
Wie kann ich in einem PHP-Script erfragen, ob ein eben gesetzter Cookie auf dem Client auch angenommen wurde? Das Script soll nicht enden zwischendurch.
$_COOKIE['$var']
Da steht direkt nach dem Aufruf von setcookie() noch nichts drin. Die VARs werden wohl auch nur beim Scriptstart initialisiert. Wenn der Server also noch einen Kontrolldialog führt, müsst man die wohl neu laden.
In der Sessionverwaltung ist ja scheinbar auch so ein Mechanismus eingebaut. Anderenfalls könnte PHP ja keinen automatischen Fallback machen.
Also nochmal zur Verdeutlichung:
- Client ruft Script auf
- Server sendet HTTP-Header mit Cookie-Anweisung
setcookie(..); //soweit logisch
Frage: 3. Server sendet HTTP-Header mit "getCookie"?
- Client sendet Cookie zurück
mhh, eigentlich sendet er nur Cookie_accepted oder eben nicht.
Das hört sich intereressant an. Wo speichert der Server das?
- Server wertet aus und sendet das HTTÜ-Attachement.
welches attachment? in dem moment wo bei 4. ein accepted gesendet wird steht das cookie in $_COOKIE[] zur verfügung. was möchtest du sonst?
Na den "BODY" vom HTTP-Dialog
Liebe Grüße aus http://www.braunschweig.de
Tom
Hi Fabian,
lange nix mehr von dir gehört
Du hier und nicht in der Schule?
Reformationstag ist. Da bei uns über 90% der Schüler (und Leerer) evangelischen Glaubens sind fällt die Schule heute aus.
Das coole dran: Ich bin katholisch und kann morgen auch noch zuhause bleiben ;-)
Ich war ein bisschen angeschlagen die letzten Tage
Oh... gute Besserung. Lass deine Praktikanten doch für dich arbeiten. Du bekommst übrigens wohl balkd einen hinzu... die Schule fäng langsam an, das ganbze gut zu finden ;-))
Wie kann ich in einem PHP-Script erfragen, ob ein eben gesetzter Cookie auf dem Client auch angenommen wurde? Das Script soll nicht enden zwischendurch.
$_COOKIE['$var']
Da steht direkt nach dem Aufruf von setcookie() noch nichts drin. Die VARs werden wohl auch nur beim Scriptstart initialisiert. Wenn der Server also noch einen Kontrolldialog führt, müsst man die wohl neu laden.
korrekt. aber $cookie_gesetzt = setcookie(); dürfte dieses wunder vollbringen, zumindest bei mir. Ich schicke dir den scriptteil mal.
In der Sessionverwaltung ist ja scheinbar auch so ein Mechanismus eingebaut. Anderenfalls könnte PHP ja keinen automatischen Fallback machen.
setcookie(..); //soweit logisch
Frage: 3. Server sendet HTTP-Header mit "getCookie"?
nö, IMO nicht. bloß ein setcookie, das der client zu beantworten hat. das kannst du abfragen. alle sonst gültigen Cookies (also die, die vorher gesetzt wurden und noch gültig sind) werden berereits im REQUEST mitgeschickt und stehen definitiv in $_COOKIE[] zur verfügung.
- Client sendet Cookie zurück
mhh, eigentlich sendet er nur Cookie_accepted oder eben nicht.
Das hört sich intereressant an. Wo speichert der Server das?
$_COOKIE[], wo sonst, es handelt sich ja um dynamische ENV-Daten, die je nach Seite verschieden sind.
- Server wertet aus und sendet das HTTÜ-Attachement.
welches attachment? in dem moment wo bei 4. ein accepted gesendet wird steht das cookie in $_COOKIE[] zur verfügung. was möchtest du sonst?
Na den "BODY" vom HTTP-Dialog
oh den meinst du... ja wär besser wenn er das tut *g*
Liebe Grüße aus http://www.braunschweig.de
Tom
Fabian
[dessen erste mahlzeit heute das mittagessen ist]
HiLo Fabian,
Oh... gute Besserung. Lass deine Praktikanten doch für dich arbeiten.
Die sind schon fleissig. Wir wollen ja nun mal endlich mit Datenbank anfangen. Vorher noch ein bisschen flie(), readfile(), fopen(), fgets(), fwrite(), und die Arrayfunktionen. Beim Sortieren, speziell von mehrdimensionalen Arrays, habe ich auch noch Lücken. Das würde ich wohl eher in einer Hochsprache hinbekommen als mit den PHP-Funktionen.
Du bekommst übrigens wohl balkd einen hinzu... die Schule fäng langsam an, das ganbze gut zu finden ;-))
Das hört sich gut an. Mir fallen alle meine Sünden ein...
korrekt. aber $cookie_gesetzt = setcookie(); dürfte dieses wunder vollbringen, zumindest bei mir. Ich schicke dir den scriptteil mal.
$cookie_gesetzt ist bei mir immer 1, egal was man macht.
wo ist der Scriptteil?
[dessen erste mahlzeit heute das mittagessen ist]
ich sitze hier schon seit 5:45. Langsam habe ich auch Hunger.
Liebe Grüße aus http://www.braunschweig.de
Tom
HiLo Fabian,
Oh... gute Besserung. Lass deine Praktikanten doch für dich arbeiten.
Die sind schon fleissig. Wir wollen ja nun mal endlich mit Datenbank anfangen. Vorher noch ein bisschen flie(), readfile(), fopen(), fgets(), fwrite(), und die Arrayfunktionen. Beim Sortieren, speziell von mehrdimensionalen Arrays, habe ich auch noch Lücken. Das würde ich wohl eher in einer Hochsprache hinbekommen als mit den PHP-Funktionen.
stimmt, das ist extrem nervig, immer wieder diese verschachtelten foreach{} zu haben...
Du bekommst übrigens wohl balkd einen hinzu... die Schule fäng langsam an, das ganbze gut zu finden ;-))
Das hört sich gut an. Mir fallen alle meine Sünden ein...
Hmm? Mir fällt da nur eine ein, aber das hat Zeit, bis unser "Konsortium", dass sich wohl aus Schulleitung, Praktikumsvorstand und Informatikfachobmann mit mir weiterführende Gespräche anstregt, was bis mindestens nächste Woche dauern wird.
korrekt. aber $cookie_gesetzt = setcookie(); dürfte dieses wunder vollbringen, zumindest bei mir. Ich schicke dir den scriptteil mal.
$cookie_gesetzt ist bei mir immer 1, egal was man macht.
echt? Hast du das auch mit deaktivierten Cookies im Browser probiert? In meinem Scriptfall ist das nicht schlimm, weil schlicht nix passiert, aber bei dir müsste man in dem Fall, wie Christian das vorschlägt echt mit Location-Headern arbeiten.
Oder andere Idee: bringt es was, wenn man ein script extern über exec(); ausführt? Ich glaube, dass das nicht geht, da es keinen header bekommt, aber nen Versuch isses wert.
wo ist der Scriptteil?
<?php
if($_GET['theme'] != "" && $_GET['theme'] != $_COOKIE['theme'])$theme = $_GET['theme'];
else $theme = $_COOKIE['theme'];
if($theme == "")$theme = 0; // in deinem fall müsste hier ein Location-header kommen, auf das script, dass das Cookie setzt.
$cs = setcookie("theme",$theme,$time+7290000);
if(!$cs)header("Location: cookie_setzen.php"); // ist bei mir nicht drin...
//restlicher Code
?>
wie gesagt, bei diesem Script ist es irrelevant, ob das Cookie gesetzt wird oder nicht, denn wer Cookies deaktiviert hat, der hat halt pech, da $theme dann immer 1 wird.
[dessen erste mahlzeit heute das mittagessen ist]
ich sitze hier schon seit 5:45. Langsam habe ich auch Hunger.
oh... mahlzeit =)
Liebe Grüße aus http://www.braunschweig.de
Tom
Fabian
Hallo Thomas,
Wie kann ich in einem PHP-Script erfragen, ob ein eben gesetzter Cookie auf dem Client auch angenommen wurde?
Das geht (s.u.)
Das Script soll nicht enden zwischendurch.
Das geht nicht. Der Cookie wird vom Browser erst bei der zweiten Seitenanfrage gesendet. Du kannst als Server keinen Header an den Browser senden, der den Browser veranlasst, darauf zu antworten. Du kannst es ihm nur empfehlen. (30x + Location)
In der Sessionverwaltung ist ja scheinbar auch so ein Mechanismus eingebaut. Anderenfalls könnte PHP ja keinen automatischen Fallback machen.
Die Sessionverwaltung häng die SID an die URL an, wenn kein Cookie gesetzt ist, also auch beim ersten mal. Bei der zweiten Seite ist das Cookie gesetzt, also wird die SID nicht mehr angehängt. Wenn keine Cookies aktiv sind, dann findet er nie das Cookie, also hängt er die SID immer wieder an. (sofern url_rewriting an ist)
Wie Du das mit Deinen Cookies machen kannst:
Aufruf von seite1.php:
(ist cookie gesetzt?)
JA: mach was die Seite soll
NEIN: Leite per Location-Header auf seite1.php?cookietest=1 weiter
Aufruf von seite1.php?cookietest=1:
(ist cookie gesetzt?)
JA: mach was die Seite soll
NEIN: Reagiere darauf
Grüße,
Christian
Hallo Christian,
Aufruf von seite1.php:
(ist cookie gesetzt?)
JA: mach was die Seite soll
NEIN: Leite per Location-Header auf seite1.php?cookietest=1 weiter
Aufruf von seite1.php?cookietest=1:
(ist cookie gesetzt?)
JA: mach was die Seite soll
NEIN: Reagiere darauf
Wir haben es jetzt so ähnlich gemacht. Wir senden einfach als letztes Statement im HTTP-Header einen Relocation-Self;Exit;
Nur produziert man dadurch eine Endlosschleife.
Der Vorschlag von Fabian, nach is_cookie_accepted Ausschau zu halten, gefällt mir da schon besser. Aber in welcher Variable steht das drin und wann?
Grüße
Tom
Hallo Thomas,
Nur produziert man dadurch eine Endlosschleife.
Dann hast Du irgendwas falsch gemacht. Ich schreib' jetzt mal einen Beispielcode:
<?php
if (!isset($_COOKIE["name"])) {
if (!isset($_GET["cookietest"])) {
echo "Ihr Browser unterstützt keine Cookies.";
exit;
} else {
setcookie (...);
Header ("Location: http://" . $_SERVER["HTTP_HOST"] . $_SERVER["PHP_SELF"] . "?cookietest=1");
exit;
}
}
/* hier der normale code */
?>
Grüße,
Christian
Hi!
<?php
if (!isset($_COOKIE["name"])) {
if (!isset($_GET["cookietest"])) {
echo "Ihr Browser unterstützt keine Cookies.";
exit;
} else {
setcookie (...);
Header ("Location: http://" . $_SERVER["HTTP_HOST"] . $_SERVER["PHP_SELF"] . "?cookietest=1");
exit;
}
}
/* hier der normale code */
?>
Genau so habe ich es auch gemeint.
Grüße
Andreas
Hallo!
Wie kann ich in einem PHP-Script erfragen, ob ein eben gesetzter Cookie auf dem Client auch angenommen wurde?
Über $_COOKIE(http://www.php3.de/manual/de/language.variables.predefined.php)
Das Script soll nicht enden zwischendurch.
wie stellst Du Dir das vor? Das Script wird auf dem Server ausgeführt, dann sendet der Server die Daten wie Cookies.... an den Client, und je nach dem was der Client macht kommt ein neuer Request an ein neues Script. Das kannst Du natürlich mit einem Redirect-Header erzwingen, ohne das der Client was merkt.
In der Sessionverwaltung ist ja scheinbar auch so ein Mechanismus eingebaut.
Nein, sowas geht nicht. Auch da wird der Session_cookie an den Client gesendet, und erst im _nächten_ Script kannst Du prüfen ob der Cookie gesendet wurde.
Anderenfalls könnte PHP ja keinen automatischen Fallback machen.
Das Session-Modul ist auch kein PHP-Code. Vielleicht hilft Dir
http://www.chipchapin.com/WebTools/cookietest.php?mode=3
http://www.php3.de/manual/de/function.get-browser.php
http://www.php3.de/manual/de/function.setcookie.php(Kommentare)
Also nochmal zur Verdeutlichung:
- Client ruft Script auf
- Server sendet HTTP-Header mit Cookie-Anweisung
- Server sendet HTTP-Heder mit ????? getCookie
- Client sendet Cookie zurück
- Server wertet aus und sendet das HTTÜ-Attachement.
Warum machst Du das nicht? Du kannst ja einfach _vor_ dem eigentlichen Script einen Cookie setzen und mit header() auf das eigentlich eScript leiten, und in diesem Prüfen ob der Cookie existiert. Das ist der einzig sichere Weg, oder du verwendest Sessions.
funktioniert die Archiv-Suche nicht mehr, oder bin ich zu blöd?
weiß ich auch nicht, aber ich teste gerade mit einer MySQL-Suche durch das Archiv 2002, vielleicht hilft es ja!
http://selfarchiv.knet-systems.de/
Grüße
Andreas
Hallo Andreas,
http://www.chipchapin.com/WebTools/cookietest.php?mode=3
http://www.php3.de/manual/de/function.get-browser.php
http://www.php3.de/manual/de/function.setcookie.php
es sammelt sich langsam...:-))
Warum machst Du das nicht? Du kannst ja einfach _vor_ dem eigentlichen Script einen Cookie setzen und mit header() auf das eigentlich eScript leiten, und in diesem Prüfen ob der Cookie existiert. Das ist der einzig sichere Weg, oder du verwendest Sessions.
Hab ich ja so gemacht. das gibt nur ne Endlosschleife.
Grüße
Tom
Hi!
Hab ich ja so gemacht. das gibt nur ne Endlosschleife.
Dann machst Du was falsch. Wie sieht der entscprechnede Code-Auszug denn aus?
Grüße
Andreas
Holla Andreas,
Hab ich ja so gemacht. das gibt nur ne Endlosschleife.
Dann machst Du was falsch. Wie sieht der entscprechnede Code-Auszug denn aus?
Here we go...
<?
define("N","<br />");
if(!$HTTP_COOKIE_VARS["COOK"])
{
$ok = setcookie("COOK", "Hello", time()+6000, "", "192.168.101.99", 0);
$meldung="Cookie wurde angelegt!<br />";
}
elseif($COOK)
{
$meldung="Vorhandenes Cookie Wurde Gelesen: <br>".
$cookie_A.N;
}
if(!$HTTP_COOKIE_VARS["COOK"])
{
header("Location: http://192.168.101.99/~katja/cookie/set_cookie_A.php");
exit;
}
?>
<!-- Hier beginnt das HTML-Dokument -->
<html>
<head>
</head>
<body>
<?
echo $meldung.N;
?>
<table width="80%" rules="all">
<caption align="left"><h1>Cookievariablen</h1></caption>
<tr>
<th align="left">Index aus Array</th>
<th align="left">Wert der Variablen</th>
<th align="left">Wert aus der Globalv</th>
</tr>
<?
foreach ($HTTP_COOKIE_VARS as $key => $value)
{
echo "<tr>
<td><b>$key</b></td>
<td>$value</td>
<td>".$$key."</td>
</tr>";
}
?>
</table>
<script type="text/javascript">
<!--
function getCookies()
{
document.write("<br />Cookielaenge: "+document.cookie.length + "<br />");
document.write("<br />Cookieinhalt: "+document.cookie + "<br />");
}
//-->
</script>
<?
echo "Cookie Result: ".$ok."<br />";
?>
<script>
getCookies();
</script>
</body>
</html>
Damit haben wir gerade unseren Testserver ins Nirwana transportiert, bzw. das PHP-Modul.
Grüße
Tom
Hallo Thomas,
if(!$HTTP_COOKIE_VARS["COOK"])
{
header("Location: http://192.168.101.99/~katja/cookie/set_cookie_A.php");
exit;
}
Hiermit leitest Du *immer* auf die eigene Datei weiter, wenn das Cookie nicht existiert. Wenn das Cookie nicht akzeptiert wird, dann existiert es aber auch nie. Und daher kommt Deine endlosschleife.
Du musst auf set_cookie_A.php?testcookie=1 o.ä. weiterleiten und wenn $_GET["testcookie"]==1 ist *und* das Cookie nicht da ist, dann gibt es keine Cookie-Unterstützung, wenn $_GET["testcookie"] nicht gesetzt ist und das Cookie auch nicht existiert, dann machst Du die Weiterleitung.
Betriebsblindheit?
Grüße,
Christian
Hallo Chris,
if(!$HTTP_COOKIE_VARS["COOK"])
{
header("Location: http://192.168.101.99/~katja/cookie/set_cookie_A.php");
exit;
}
Hiermit leitest Du *immer* auf die eigene Datei weiter, wenn das Cookie nicht existiert. Wenn das Cookie nicht akzeptiert wird, dann existiert es aber auch nie. Und daher kommt Deine endlosschleife.
Betriebsblindheit?
Nee, ich weiß ja, dass das so nicht geht. War ja nur ein erster Versuch. Und wenn man die Cookies dan ablehnt am Client, gibts eben die Endlosschleife. Das hatte ich gerade gesagt, da wars schon zu spät und Katja hatte auf den Knopf gedrückt.
Wir haben ja eine Möglchkeit gesucht, den Server und den Client noch während des Scriptes auf LowLevel-Ebene zu einem kleinen HTTP-Dialog aufzufodern. Ich habe auch schon ein paar Tipps gesammelt. Leider kann ich sie jetzt nicht mehr ausprobieren, weil eir den PHP-Deamon geplättet haben.
Grüße
Tom
Hallo!
Wir haben ja eine Möglchkeit gesucht, den Server und den Client noch während des Scriptes auf LowLevel-Ebene zu einem kleinen HTTP-Dialog aufzufodern.
und das ist eben unmöglich.
Was meinst Du mit "low-Level Ebene"? Wenn Du das ganze mit PHP lösen willst geht es eben nicht anders als es unten beschreiben wurde, und andere Leute setzen das auch erfolgreich so ein!
Ich habe auch schon ein paar Tipps gesammelt. Leider kann ich sie jetzt nicht mehr ausprobieren, weil eir den PHP-Deamon geplättet haben.
Seit wann läuft PHP als Daemon?
Und wieso kannst Du den Apache nicht einfach neu starten?
Grüße
Andreas
Hallo Andreas,
da wächst es schon wieder, das Gefühl des Unmutes.
Wir haben ja eine Möglchkeit gesucht, den Server und den Client noch während des Scriptes auf LowLevel-Ebene zu einem kleinen HTTP-Dialog aufzufodern.
und das ist eben unmöglich.
Was meinst Du mit "low-Level Ebene"? Wenn Du das ganze mit PHP lösen willst geht es eben nicht anders als es unten beschreiben wurde, und andere Leute setzen das auch erfolgreich so ein!
Vielleicht haben die eine neuere PHP-Version im Einsatz, die schon $_COOKIE kennt oder sie haben eventuell uach nicht so genaus hingeschaut, wie wir. $HTTP_*_VARS werden nur bei Scriptstart initialisiert.
Ich habe auch schon ein paar Tipps gesammelt. Leider kann ich sie jetzt nicht mehr ausprobieren, weil eir den PHP-Deamon geplättet haben.
Die RFC-2109 sollte man gelesen haben, wenn man mit Cookies hantiert. Da wird einem klar, dass es eben einen HTTP-Dialog geben muss und dass man auch in PHP etwas Einfluss darauf hat, wie er abläuft. Ich lag mit meiner Vermutung wahrscheinlich richtig, dass es am fehlenden Refresh der $HTTP_COOKIE_VARS liegt. Hat jemand einen Server mit $_COOKIE laufen?
Seit wann läuft PHP als Daemon?
Als Tochterprozess des Apache-Deamon wird auch PHP zum Deamon-Prozess. Bei mir hat PHP jedenfalls keine Konsole. Gibts das überhaupt? Eine Konsole für Apache und/oder PHP?
Und wieso kannst Du den Apache nicht einfach neu starten?
Ach Andreas, das ist jetzt die Stelle! Du implizierst, ich könnte Apache nicht neu starten, statt das du fragst. Schaus Die an, wie Christian geantwortet hat. Der trifft im Grunde die gleichen Aussagen, aber verwendet eine andere Ausdrucksweise.
Wir haben Apache neu gestartet
Wir haben den Server neu gestartet
Wir haben damit keinen Erfolg gehabt
Wir haben Apache und PHP neu von der CD auf die Platte übertragen
Die ini-Datei und die httpd.conf wurden dabei nicht zerstört.
Jetzt läuft es wieder.
Grüße
Andreas
Hallo Thomas,
Vielleicht haben die eine neuere PHP-Version im Einsatz, die schon $_COOKIE kennt oder sie haben eventuell uach nicht so genaus hingeschaut, wie wir. $HTTP_*_VARS werden nur bei Scriptstart initialisiert.
Natürlich werden HTTP_*_VARS nur beim Scriptstart initialisiert, wann denn sonst?
Die RFC-2109 sollte man gelesen haben, wenn man mit Cookies hantiert. Da wird einem klar, dass es eben einen HTTP-Dialog geben muss und dass man auch in PHP etwas Einfluss darauf hat, wie er abläuft. Ich lag mit meiner Vermutung wahrscheinlich richtig, dass es am fehlenden Refresh der $HTTP_COOKIE_VARS liegt. Hat jemand einen Server mit $_COOKIE laufen?
O weh! Mit "Dialog" ist aber etwas anderes gemeint:
1: Client stellt Anfrage
2: Server Antwortet
Mehr nicht. Wenn "weitergequatscht" werden soll, dann muss der Client weitere Anfragen senden. Während *einer* Anfrage eine Kommunikation durchzuführen geht mit HTTP nicht - ist ja schließlich zustandslos. Ich glaube, RFC 2616 wäre die bessere Lektüre... (und RFC 2109 vielleich als Zusatz)
Als Tochterprozess des Apache-Deamon wird auch PHP zum Deamon-Prozess.
Nein. PHP ist ein Shared Object (da du Linux verwenest, unter Windows eine DLL) und wird daher nur zum Apache dazugeladen und ist auch kein Tochterprozess. (aber Apache bildet selbst tochterprozesse) Wenn Du PHP als CGI installiert hast, dann ist das zwar Tochterprozess, aber kein Daemon, da es ja linear abarbeitet und nicht auf Anfragen wartet.
Gibts das überhaupt? Eine Konsole für Apache und/oder PHP?
Nicht dass ich wüßte - warum auch? Was willst Du denn dem Apache sagen können? Neuladen der Config über SIGHUP, beenden über SIGTERM - sonst brauchst Du nichts.
Wir haben Apache neu gestartet
Wir haben den Server neu gestartet
Wir haben damit keinen Erfolg gehabt
Ach Du Sch****se... Das kann ich mir aber nun gar nicht erklären :-(
Wir haben Apache und PHP neu von der CD auf die Platte übertragen
Die ini-Datei und die httpd.conf wurden dabei nicht zerstört.
Jetzt läuft es wieder.
Wenigstens etwas...
Grüße,
Christian
Guten Morgen Christian,
Vielleicht haben die eine neuere PHP-Version im Einsatz, die schon $_COOKIE kennt oder sie haben eventuell uach nicht so genaus hingeschaut, wie wir. $HTTP_*_VARS werden nur bei Scriptstart initialisiert.
Natürlich werden HTTP_*_VARS nur beim Scriptstart initialisiert, wann denn sonst?
Die RFC-2109 sollte man gelesen haben, wenn man mit Cookies hantiert. Da wird einem klar, dass es eben einen HTTP-Dialog geben muss und dass man auch in PHP etwas Einfluss darauf hat, wie er abläuft. Ich lag mit meiner Vermutung wahrscheinlich richtig, dass es am fehlenden Refresh der $HTTP_COOKIE_VARS liegt. Hat jemand einen Server mit $_COOKIE laufen?
O weh! Mit "Dialog" ist aber etwas anderes gemeint:
1: Client stellt Anfrage
2: Server Antwortet
Das habe ich aber anders verstanden. Aus der RFC-2109 geht der Vorgang so hervor:
1. Client sendet Seitenanfrage
2. Server sendet Frage, ob er ein Cookie senden darf
3. Client antwortet mit ja oder nein
4. Server sendet Cookie und Seite
5. Client sendet ein ACK für das Cookie
Und es steht da drin, dass dieser Dialog in nder Praxis verkürzt wurde auf:
1. Client sendet Seitenanfrage
2. Server sendet Frage, ob er ein Cookie setzen darf, Cookie und Seite
3. Client sendet ein NACK oder ACK zurück für das Cookie
Wenn die Antwort also auf dem Server zur Verfügung steht, dann will ich sie verflixt nochmal auch auswerten. Angeblich soll das ab PHP 4.2.x mit $_COOKIE auch möglich sein, da die neuen Variablen nach Hörensagen dynamisch aktualisiert werden. Ich habe es aber noch nicht installiert. Muss dann wohl mal machen, wenn mir hier keiner helfen kann.
Ich will's eben genau wissen. Ist ein Virus *gg*
Grüße
Tom
Morgen Tom,
Das habe ich aber anders verstanden. Aus der RFC-2109 geht der Vorgang so hervor:
Sprechen wir vom gleichen RFC?
http://www.ietf.org/rfc/rfc2109.txt
- Client sendet Seitenanfrage
- Server sendet Frage, ob er ein Cookie senden darf
- Client antwortet mit ja oder nein
- Server sendet Cookie und Seite
- Client sendet ein ACK für das Cookie
Nenn mir bitte den entsprechenden Textausschnitt - ich habe mir das RFC noch einmal durchgelesen und nichts derartiges gefunden.
Und es steht da drin, dass dieser Dialog in nder Praxis verkürzt wurde auf:
- Client sendet Seitenanfrage
- Server sendet Frage, ob er ein Cookie setzen darf, Cookie und Seite
- Client sendet ein NACK oder ACK zurück für das Cookie
Das sehe ich auch nirgendwo.
So wie ich das RFC verstanden habe passiert folgendes:
1. Client sendet Anfrage
2. Server antwortet mit setCookie-Header
3. Client sendet u.U. noch eine Anfrage diesmal mit Cookie-Header
4. Server antwortet wieder, evtl. mit setCookie-Header
5. usw.
HTTP ist wie gesagt ein zustandsloses Protokoll. Zitat aus dem RFC:
| (Note that "session" here does not refer
| to a persistent network connection but to
| a logical session created from HTTP requests
| and responses.
Wenn die Antwort also auf dem Server zur Verfügung steht,
AFAIK/IMHO tut sie das eben nicht. Die Anfrage ist erst abgeschlossen, wenn das PHP-Script abgeschlossen ist. Danach sendet der Browser erst (u.U.) eine weitere Anfrage.
Grüße,
Christian
Hallo!
AFAIK/IMHO tut sie das eben nicht. Die Anfrage ist erst abgeschlossen, wenn das PHP-Script abgeschlossen ist. Danach sendet der Browser erst (u.U.) eine weitere Anfrage.
Genau so ist es. Und in $_COOKIE steht auch nichts dynamisches, wie soll das mit PHP funkionieren? Vor Start des Scriptes werden die globalen Variablen initiiert, dann ändert sich daran nichts mehr. Dann werden dem Script ewntsprechend HEADER und Body an den Client geschickt, udn der kann wenn er möchte einen euen Request starten, an ein anderes Script, oder an dasselbe Script, dann wird es aber komplett neu aufgerufen, und nicht mittendrin.
In PHP hast Du definitiv keinen direkten Zugriff auf POST, COOKIE oder originale Daten. Du bekommst nur das was PHP dir gibt.
Man bedenke das PHP eie recht einfache und nicht wirklich "mächtige" Programmiersprache ist, die gerade aufgrund der Einfachheit vielen Einschränkungen unterworfen ist.
Viele Grüße
Andreas
PS: Mit meinem Apachen(2) hatte ich auch schon Probleme, da half manchmal nur ein reboot des Systems.
Hallo Andreas,
AFAIK/IMHO tut sie das eben nicht. Die Anfrage ist erst abgeschlossen, wenn das PHP-Script abgeschlossen ist. Danach sendet der Browser erst (u.U.) eine weitere Anfrage.
Dass da innerhalb der Gültigkeitsdauer des Scriptes kein HTTP-Dialog stattfinden kann, nehme ich Dir nicht ab.
Was ist denn z.B. mit dem Auth-Verfahren über Header und error 401?
Da wird doch auch dreimal hin und her jongliert, obwohl der Körper des HTTP-Dokuments (_nicht_ HTML) noch gar nicht gesendet wurde.
Du hast mich noch nicht überzeugt.
Tom
Hallo Thomas,
Was ist denn z.B. mit dem Auth-Verfahren über Header und error 401?
Ganz einfach:
Client stellt Anfrage
Server antwortet mit 401 und vollständigem Fehlerdokument
(Wenn der Benutzer hier auf Escape drückt, dann wird das Fehlerdokument angezeigt, ansonsten weiter)
Client antwortet mit Benutzernamen und Passwort
Server liefert Seite aus
Du kannst als Server den Client *während* einer Verbindung nicht veranlassen, weitere Header zu senden. Der Client muss immer eine neue Anfrage starten. Ob die jetzt auf dem gleichen Datenkanal passiert (Persisten Connections) oder nicht, ist egal.
Kann denn niemand uns (Andreas, mir) hier zustimmen, der am HTTP-Protokollentwurf beteiligt war? Wenn Du _mir_ schon nicht glaubst, Tom?
Da wird doch auch dreimal hin und her jongliert, obwohl der Körper des HTTP-Dokuments (_nicht_ HTML) noch gar nicht gesendet wurde.
Doch - der wird gesendet!
Du hast mich noch nicht überzeugt.
^^^^
hoffe das wird noch ;-)
Grüße,
Christian
P.S.: Nur mal so nebenbei: RFC 2109 wurde von ftp://ftp.rfc-editor.org/in-notes/rfc2965.txt obsoleted - tut aber nichts zur Sache.
Hallo!
Was ist denn z.B. mit dem Auth-Verfahren über Header und error 401?
Ganz einfach:
Client stellt Anfrage
Server antwortet mit 401 und vollständigem Fehlerdokument
(Wenn der Benutzer hier auf Escape drückt, dann wird das Fehlerdokument angezeigt, ansonsten weiter)
Client antwortet mit Benutzernamen und Passwort
Server liefert Seite aus
Du kannst als Server den Client *während* einer Verbindung nicht veranlassen, weitere Header zu senden. Der Client muss immer eine neue Anfrage starten. Ob die jetzt auf dem gleichen Datenkanal passiert (Persisten Connections) oder nicht, ist egal.
Kann denn niemand uns (Andreas, mir) hier zustimmen, der am HTTP-Protokollentwurf beteiligt war? Wenn Du _mir_ schon nicht glaubst, Tom?
Da wird doch auch dreimal hin und her jongliert, obwohl der Körper des HTTP-Dokuments (_nicht_ HTML) noch gar nicht gesendet wurde.
Doch - der wird gesendet!
Du hast mich noch nicht überzeugt.
^^^^
hoffe das wird noch ;-)
ich befürchte nicht ;-)
Aber um bei Deinem jonglierenden Auth-Verfahren zu bleiben, dazu steht folgendes ganz am Anfang des Kapitels im Manual(http://www.php3.de/manual/de/features.http-auth.php):
<quote>
In einem PHP-Skript für ein Apache-Modul kann man die Funktion header() benutzen, um die
Nachricht "Authentifizierung notwendig" an den Client-Browser zu senden, damit dieser ein
Fenster zur Eingabe von Benutzername/Passwort öffnet. Hat der Benutzer diese eingegeben, wird
die URL des PHP-Scripts mit den Variablen $PHP_AUTH_USER, $PHP_AUTH_PW und $PHP_AUTH_TYPE,
die den jeweiligen Benutzernamen, das Passwort und den Typ der Identifizierung enthalten,
erneut aufgerufen.
^^^^^^^^^^^^^^^^^ <= das sind die entscheidenen Worte!
</quote>
Das Beispiel dazu sieht so aus:
<?php
if(!isset($PHP_AUTH_USER)) {
Header("WWW-Authenticate: Basic realm="My Realm"");
Header("HTTP/1.0 401 Unauthorized");
echo "Text to send if user hits Cancel button\n";
exit;
} else {
echo "Hello $PHP_AUTH_USER.<P>";
echo "You entered $PHP_AUTH_PW as your password.<P>";
}
?>
wenn das Script ohne $PHP_AUTH_USER aufgerufen wird, dann wird der entsprechende Header gesendet, der das auth-Fenster beim Client öffnet. Wenn Benutzername eingegeben und auf OK gedrückt wird, wird der Pfad erneut aufgerufen, mit dem Unterschied dass diesmal $PHP_AUTH_USER gesetzt ist, also reagiert if... anders. Sicher, das steht in _einem_ Scipt, dieses wird aber 2 mal aufgerufen, mit verschiedenen Umgebungsvariablen. Und haargenauso funktioniert das mit den Cookies! Ich hoffe Du glaubst wenigstens dem Manual...
HTTP ist zustandslos, das ist so! Nicht mit TCP/IP verwechseln, da wird "jongliert" aber das ist eine andere Ebene. Zustandslos ist aber für bestimmte Anwendungen - wie eben Authentifizierung - nicht gut, daher wird versucht so gut wie eben möglich mit den gegebenen Beschränkungen des HTTP-Standards ein echtes Login zu emulieren. Aber egal was man macht, es wird nie so sicher sein wie z.B. SSH, denn hier ist man nicht an die Schranken des HTTP-Protokolls gebunden.
Grüße
Andreas
PS: Aber genau das hatte Christian ja bereits geschrieben!
Guten Morgen Christian,
Nenn mir bitte den entsprechenden Textausschnitt - ich habe mir das RFC noch einmal durchgelesen und nichts derartiges gefunden.
Die Stelle ist Ch. 4.2.1
Grüße
Tom
N'abend Tom,
Nenn mir bitte den entsprechenden Textausschnitt - ich habe mir das RFC noch einmal durchgelesen und nichts derartiges gefunden.
Die Stelle ist Ch. 4.2.1
Argh! Die Stelle ist blöd geschrieben und sie erlaubt Deine Interpretation. Aber es ist trotzdem falsch. Das HTTP-Protokoll ist nun mal auf Frage->Antwort ausgelegt und erlaubt keine Gegenfragen.
Grüße,
Christian
Hallo zusammen!
Nenn mir bitte den entsprechenden Textausschnitt - ich habe mir das RFC noch einmal durchgelesen und nichts derartiges gefunden.
Die Stelle ist Ch. 4.2.1
Argh! Die Stelle ist blöd geschrieben und sie erlaubt Deine Interpretation. Aber es ist trotzdem falsch. Das HTTP-Protokoll ist nun mal auf Frage->Antwort ausgelegt und erlaubt keine Gegenfragen.
Nein, erlaubt sie nicht, der 2. Satz lautet wie folgt:
(Note that
"session" here does not refer to a persistent network connection but
to a logical session created from HTTP requests and responses. The
presence or absence of a persistent connection should have no effect
on the use of cookie-derived sessions)
es geht hier um _LOGIK_, eine "logische Session", keine persistente Verbindung mit handshake... Wie das im einzelnen funktioniert haben Christian und ich bereits geschrieben. Das war es was ich mit "login emulieren" meinte. Man tut so als hätte man eine echte Session über eine persistente Verbindung, hat man aber in Wirklichkeit nicht.
Und es tut mir Leid das es uns nichtg gelingt Deine Zweifel auszuräumen, aber das ist auch nicht unser Job, wir können Dir nur Hilfen geben. Wenn Du das alles immer noch nicht glauben magst, dann probiere es doch einfach selbst aus, erzeuge Deine Header so wie Du es Dir vorstellst und prüfe wie das alles auf HTTP-Protokoll-Ebene funktioniert, entweder mit telnet oder mit http://forum.de.selfhtml.org/cgi-bin/http_trace.pl.
Anstatt zu sagen "überzeugt mich nicht", überzeug uns doch mal vom Gegenteil! Wenn Du das schaffst würdest Du mein Verständnis des Internet auf den Kopf stellen! Wenn das keine Herausforderung ist ;-)
Grüße
Andreas