register_globals off, Frage dazu

[Herbie]

Hi,
nachdem nun endlich nach viel Schweiß und Tränen (kein Blut) und etwas Hilfe von diesem Forum meine nagelneue WAMP-Testumgebung steht, mit den  jeweils neuesten stabilen Versionen von Apache (1.3-Branch), PHP und MySQL (noch nicht die 4er), bin ich auch wie so viele vor mir hart auf das register_globals off Problem aufgeschlagen. Habe also brav meine bla$-Variablen in $_REQUEST[bla] umgewandelt, und schon flutscht das alte Zeug wieder.

Aber: In der PHP.ini-recommended (v4.3) steht, dass man $_REQUEST[bla] verwenden kann, oder eben konkreter $_POST[bla], $_GET[bla] und so weiter. Da $_REQUEST[bla] ja alles abdeckt, fragt man sich als Halblaie, wieso es eigentlich $_POST[bla] und so weiter auch noch gibt - das wird doch sicher einen Grund haben? Kennt den jemand?

Und:
In einem meiner scripts steht folgendes:

if ($_REQUEST[posted])
...
aufgerufen wird das mit:
<form action="test.php?posted=yes" method=POST>

so klappt es, aber mit if ($_POST[posted]) klappt es nicht. Verstehe ich nicht... die Methode des Formulars, das per submit loslegt ist doch POST? Wieso will die Abfrage dann $_REQUEST?

Thx schonmal für Antworten,
Herbie

[Harry]

Holladiewaldfee,

Aber: In der PHP.ini-recommended (v4.3) steht, dass man $_REQUEST[bla] verwenden kann, oder eben konkreter $_POST[bla], $_GET[bla] und so weiter. Da $_REQUEST[bla] ja alles abdeckt, fragt man sich als Halblaie, wieso es eigentlich $_POST[bla] und so weiter auch noch gibt - das wird doch sicher einen Grund haben? Kennt den jemand?

Manchmal will man einfach zwischen GET- und POST-Variablen unterscheiden. Z.b. wenn Du verhindern willst, daß sich jemand ein Bookmark für einen Login-Dialog legt (Form: x.php?user=bla&pass=foo). Dann frägst Du einfach $_POST ab und schon schaut derjenige mit seinem Bookmark in die Röhre.

if ($_REQUEST[posted])

Foisch! posted muß in Anführungszeichen: $_REQUEST["posted"]

<form action="test.php?posted=yes" method=POST>

Auch hier solltest Du POST in Anführungszeichen schreiben, auch wenn es die Browser ohne diese auch verstehen ...

so klappt es, aber mit if ($_POST[posted]) klappt es nicht. Verstehe ich nicht... die Methode des Formulars, das per submit loslegt ist doch POST? Wieso will die Abfrage dann $_REQUEST?

Wie gesagt: Die fehlenden Anführungszeichen.

Ciao,

Harry

[Christian Seiler]

Hallo Harry,

Foisch! posted muß in Anführungszeichen: $_REQUEST["posted"]

Nein. Es _muss_ nicht, ist aber besserer Stil. Und wenn wir gerade dabei sind: Doppelte Anführungszeichen sollte man _nur dann_ verwenden, wenn man Variablenersetzungen braucht. Dann muss der Parser weniger tun. (Bei einem String ist es egal, aber das summiert sich)

<form action="test.php?posted=yes" method=POST>

Auch hier solltest Du POST in Anführungszeichen schreiben, auch wenn es die Browser ohne diese auch verstehen ...

Laut HTML4 müssen _nur dann_ Anführungszeichen verwendet werden, wenn der Wert des Attributs aus mehr Zeichen als bloß Ziffern und Buchstaben besteht. Erst bei XHTML muss immer gequotet werden. (Was natürlich nicht heißt, dass es nicht besserer Stil ist, auch bei HTML4 immer zu quoten)

Wie gesagt: Die fehlenden Anführungszeichen.

Nein, die fehlenden Anführungszeichen würden sich nur dann bemerkbar machen, wenn es auch eine Konstante mit dem Namen »test« gäbe. Der Grund liegt woanders... (siehe meine Antwort)

Christian

[Harry]

Holladiewaldfee,

Foisch! posted muß in Anführungszeichen: $_REQUEST["posted"]

Nein. Es _muss_ nicht, ist aber besserer Stil. Und wenn wir gerade dabei sind: Doppelte Anführungszeichen sollte man _nur dann_ verwenden, wenn man Variablenersetzungen braucht. Dann muss der Parser weniger tun. (Bei einem String ist es egal, aber das summiert sich)

Doch, eigentlich schon falsch. Wenn es nicht in Anführungszeichen steht interpretiert PHP das Ding als Konstante. Da die Konstante aber nicht definiert ist, wird ihr Wert als dem Namen entsprechend angenommen. Das ist also durchaus ein Unterschied.
Was die doppelten Anführungszeichen angeht, da hast Du Recht. Ist halt Gewohnheitssache ... :-)

Laut HTML4 müssen _nur dann_ Anführungszeichen verwendet werden, wenn der Wert des Attributs aus mehr Zeichen als bloß Ziffern und Buchstaben besteht. Erst bei XHTML muss immer gequotet werden. (Was natürlich nicht heißt, dass es nicht besserer Stil ist, auch bei HTML4 immer zu quoten)

Ich denke in XHTML ;-)

Ciao,

Harry

[RoterFruchtZwerg]

Hi,

Tach

Aber: In der PHP.ini-recommended (v4.3) steht, dass man $_REQUEST[bla] verwenden kann, oder eben konkreter $_POST[bla], $_GET[bla] und so weiter. Da $_REQUEST[bla] ja alles abdeckt, fragt man sich als Halblaie, wieso es eigentlich $_POST[bla] und so weiter auch noch gibt - das wird doch sicher einen Grund haben? Kennt den jemand?

Vermutlich, damit man via POST übergebene Werte einer Website nicht einfach in der URL vie GET überschreiben kann, oder grundsetzlich damit man hald weiss wie die Variable übergeben worden ist.

<form action="test.php?posted=yes" method=POST>

so klappt es, aber mit if ($_POST[posted]) klappt es nicht. Verstehe ich nicht... die Methode des Formulars, das per submit loslegt ist doch POST? Wieso will die Abfrage dann $_REQUEST?

action="test.php?postet=yes" ist meines Wissens eh nicht gültig, da es aber funktioniert ist es trotzdem logisch dass es eine GET variable ist, immerhin ist sie in der URL mit ?x=y enthalten. Wenn du sie per POST übergeben willst musst du <input type=hidden name=postet value=yes> eingeben.

Thx schonmal für Antworten,
Herbie

cu RFZ

[Christian Seiler]

Hallo Herbie,

Aber: In der PHP.ini-recommended (v4.3) steht, dass man $_REQUEST[bla] verwenden kann, oder eben konkreter $_POST[bla], $_GET[bla] und so weiter. Da $_REQUEST[bla] ja alles abdeckt, fragt man sich als Halblaie, wieso es eigentlich $_POST[bla] und so weiter auch noch gibt - das wird doch sicher einen Grund haben? Kennt den jemand?

Ganz einfach: Mit $_POST['bla'], $_GET['bla'] und $_COOKIE['bla'] weiß man _genau_, _woher_ eine Variable kommt. Ich habe noch nie $_REQUEST verwendet, weil es IMHO das Konzept von register_globals=off untergräbt.

<form action="test.php?posted=yes" method=POST>

so klappt es, aber mit if ($_POST[posted]) klappt es nicht. Verstehe ich nicht... die Methode des Formulars, das per submit loslegt ist doch POST?

Klar, aber in $_POST stehen nur diejenigen Parameter, die auch mit POST übermittelt wurden, posted=yes steht aber im Query-String und deswegen wird es von PHP als GET-Parameter angesehen. (Die Methode, mit der ein Formular abgeschickt worden ist, spielt nur für Variablen eine Rolle, die aus den Formularfeldern erzeugt werden - wenn Du bei einem POST-Formular noch weitere Parameter an die URL anhängst, dann werden sie halt als GET-Parameter gewertet, auch wenn das Formular mit POST abgeschickt wurde)

Wieso will die Abfrage dann $_REQUEST?

Weil sie auch in $_GET steht. Und $_REQUEST ist ja $_GET + $_POST + $_COOKIE.

Christian

[Harry]

Holladiewaldfee,

Ganz einfach: Mit $_POST['bla'], $_GET['bla'] und $_COOKIE['bla'] weiß man _genau_, _woher_ eine Variable kommt. Ich habe noch nie $_REQUEST verwendet, weil es IMHO das Konzept von register_globals=off untergräbt.

Naja, es gibt einfach Situationen, da ist es einem a) vollkommen Wurscht, woher die Variablen kommen oder b) nicht vorauszusehen, ob die Variablen über ein GET- oder ein POST-Request ankommen.

Der Hauptgrund für register_globals=off ist ja so weit ich mich erinnern kann, der, die Session-Variablen aus dem globalen Namensraum rauszuhalten und damit zu verhindern, daß sie aus welchem Grund auch immer (meistens schlampige oder unvorsichtige (was an sich das gleiche ist) Programmierung) mit Variablen aus dem Request überschrieben werden.

Beispiel:

if($pass="ichbintoll")
 $authenticated = true;

if($authenticated==true)
 blafoo;

Nun gibt es einen Haufen Spezialisten, die $authenticated nicht vorher explizit als false definieren oder die erste Abfrage mit einer else-Verzweigung versehen. Dann würde einem Angreifer bla.php?authenticated=true Tür und Tor öffnen.

<form action="test.php?posted=yes" method=POST>

Ist so eine Konstruktion überhaupt erlaubt?

Ciao,

Harry

[Christian Seiler]

Hallo Harry,

Ist so eine Konstruktion überhaupt erlaubt?

Nenne mir den Standard, von dem Du vermutest, dass diese Konstruktion ihn untergräbt. Ich wüßte keinen...

Christian

[Harry]

Holladiewaldfee,

Ist so eine Konstruktion überhaupt erlaubt?

Nenne mir den Standard, von dem Du vermutest, dass diese Konstruktion ihn untergräbt. Ich wüßte keinen...

HTTP 1.x

Allerdings finde ich in der Definition vom w3c (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9)auf die Schnelle keine Stelle, die a) erlaubt oder b) verbietet, daß man verschiedene Request-Methoden beliebig miteinander kombiniert.

Trotzdem kann ich mir nicht ganz vorstellen, daß man das darf.

Ciao,

Harry
 (PS: Was heißt "idempotent"? Mein Lexikon hat hier versagt :-( )

[Christian Seiler]

Hallo Harry,

daß man verschiedene Request-Methoden beliebig miteinander kombiniert.

Du kombinierst aber keine verschiedenen Request-Methoden - die Tatsache, dass PHP aus den Parametern aus der Query-String $_GET-Variablen macht, ist irreführend - im Prinzip sind das nichts anderes als Query-String-Parameter, mehr nicht. Und diese dürfen sowohl bei GET als auch bei POST auftauchen. $_QUERY wäre IMHO besser geeignet.

Trotzdem kann ich mir nicht ganz vorstellen, daß man das darf.

GET und POST komibinieren - natürlich nicht. :) Aber der Query-String hat nichts mit GET zu tun, auch wenn PHP Dir diesen Bären aufbinden will...

(PS: Was heißt "idempotent"? Mein Lexikon hat hier versagt :-( )

http://dict.leo.org/?idempotent ;-)

Naja, ich vermute, das kommt aus dem Lateinischen - und »idem« heißt ja bekanntlich derselbe/dergleiche und »potens« heißt ja fähig bzw. mächtig.

Christian

[Harry]

Holladiewaldfee,

Du kombinierst aber keine verschiedenen Request-Methoden - die Tatsache, dass PHP aus den Parametern aus der Query-String $_GET-Variablen macht, ist irreführend - im Prinzip sind das nichts anderes als Query-String-Parameter, mehr nicht. Und diese dürfen sowohl bei GET als auch bei POST auftauchen. $_QUERY wäre IMHO besser geeignet.

Tja, diesen Bären hat mir wohl nicht PHP aufgebunden, sondern ich bin da von vornherein von falschen Tatsachen ausgegangen.

GET und POST komibinieren - natürlich nicht. :) Aber der Query-String hat nichts mit GET zu tun, auch wenn PHP Dir diesen Bären aufbinden will...

Wie geht dann der Query-String in den HTTP-Header ein (Ich hab jetzt keine Testkiste da, mit der ich das auslesen könnte, bin zu faul, die entsprechende Software zu installieren und erst recht zu faul, mich durch 2596 RFCs zu wühlen ...)? Ich bin immer ganz naiv davon ausgegangen, der würde am GET-Request dranhängen (GET x.php?bla=foo) und die Zerlegung würde dann der Server übernehmen. War wohl falsch *g*. Deswegen bin ich auch davon ausgegangen, daß ein POST-Request keinen Query-String haben kann.

(PS: Was heißt "idempotent"? Mein Lexikon hat hier versagt :-( )

Naja, ich vermute, das kommt aus dem Lateinischen - und »idem« heißt ja bekanntlich derselbe/dergleiche und »potens« heißt ja fähig bzw. mächtig.

Ich kenn's nur aus Mathe. Ein Funktion bla heißt idempotent wenn bla(x) = bla(bla(x)) für alle x (wenn mich meine Erinnerung nicht total im Stich lässt). Aber irgendeinen Sinn muß es ja haben, wenn manche Leute Latein lernen ;-)

Ciao,

Harry

[Christian Seiler]

Hallo Harry,

Ich bin immer ganz naiv davon ausgegangen, der würde am GET-Request dranhängen (GET x.php?bla=foo) und die Zerlegung würde dann der Server übernehmen. War wohl falsch *g*.

Ist aber nicht falsch. Aber was hindert dich an folgendem?

POST x.php?bla=foo HTTP/1.1

Christian

[Harry]

Holladiewaldfee,

Ist aber nicht falsch. Aber was hindert dich an folgendem?

POST x.php?bla=foo HTTP/1.1

Stimmt, wäre 'ne Überlegung wert.
Ich bin verwirrt, das kommt vom Physik-Studium, das machen die mit Absicht. Die wollen sehen, wer nach 4 Semestern noch nicht in der Klapse ist, der hält wahrscheinlich die nächsten 6 auch noch durch *g*

Ciao,

Harry

[Herbie]

Hey, danke an alle für die Antworten und die interessante Diskussion - hat micht deutlich weitergebracht!
Bis zum nächsten Mal,
Herbie