PHP4.4.0 - Parameter über die URL werden nicht erkannt?

[Stefan Welscher]

Wir haben unseren Webserver (mit Apache2) jetzt von PHP 3.irgendwas auf PHP4.4.0 aufgerüstet, da es mit der alten Version mit PEAR einige Probleme gab. Jetzt nimmt PHP aber keine über die URL-Zeile übergebenen Variablen mehr an (GET-Methode bei Formularen).
Ich habe schon mal von dem Fehler gehört, kann aber gerade keine Lösung im Internet finden. Weiß einer von euch eine Lösung?

[Cheatah]

Hi,

Jetzt nimmt PHP aber keine über die URL-Zeile übergebenen Variablen mehr an

es flutet den globalen Scope nicht mit Variablen, deren Ursprung aus diversen(!) Quellen wie z.B. URL-Parametern (*nicht* Variablen! Nichts in HTTP ist Variablen auch nur ähnlich!) stammen. Richtig.

Ich habe schon mal von dem Fehler gehört, kann aber gerade keine Lösung im Internet finden.

Der Fehler war die ursprüngliche Standard-Konfiguration, die ein erhebliches Sicherheitsrisiko darstellt - und zudem kaum zu handhaben ist. Nutze vordefinierte Variablen wie z.B. $_GET, $_POST, $_REQUEST oder $_SERVER. Versuche *nicht*, den vorherigen Wackeldackel-Zustand wieder herzustellen.

Cheatah

[Stefan Welscher]

Der Fehler war die ursprüngliche Standard-Konfiguration, die ein erhebliches Sicherheitsrisiko darstellt - und zudem kaum zu handhaben ist. Nutze vordefinierte Variablen wie z.B. $_GET, $_POST, $_REQUEST oder $_SERVER. Versuche *nicht*, den vorherigen Wackeldackel-Zustand wieder herzustellen.

Cheatah

Wieso Sicherheitsrisiko?
Wenn ich kritische Variablen verwenden will, setze ich sie sie halt vorher zurück. Ist noch besser als dauernd $_GET[] schreiben zu müssen. Das sieht 1. bescheuert aus und macht 2. zu viel Arbeit beim umschreiben bisheriger Scripte und sieht 3. bescheuert aus.
Gibt es denn keinen Parameter in der php.ini der das verhalten zurückstellt?Ansonsten muss ich irgendwie doch PEAR mit PHP4.3.x ans laufen bekommen...

[Tobias Kloth]

Hallo Stefan,

Wieso Sicherheitsrisiko?

http://de2.php.net/security.globals

Wenn ich kritische Variablen verwenden will, setze ich sie sie halt vorher zurück.

Aber nur solange bis du mal eine vergisst ...

2. zu viel Arbeit beim umschreiben bisheriger Scripte

tja, da hättest du es wohl gleich richtig schreiben sollen (oder ist das Script schon _sehr_ alt?).

Das sieht 1. bescheuert aus [...] und sieht 3. bescheuert aus.

Das ist wirklich keine Grund - ob das Script deiner Meinung nach bescheuert aussieht oder nicht, ist doch wohl egal :-)

Ansonsten muss ich irgendwie doch PEAR mit PHP4.3.x ans laufen bekommen...

im Bezug auf PEAR wird es keinen Unterschied machen ob du PHP4.3.x oder PHP4.4.0 verwendest - oder meinstest du PHP3 (wie im Ursprungsposting)?

Grüße aus Nürnberg
Tobias

[Stefan Welscher]

2. zu viel Arbeit beim umschreiben bisheriger Scripte
   tja, da hättest du es wohl gleich richtig schreiben sollen (oder ist das Script schon _sehr_ alt?).

Die Scripte nicht... eher die Handbücher die ich gelesen habe ;)

Das sieht 1. bescheuert aus [...] und sieht 3. bescheuert aus.
Das ist wirklich keine Grund - ob das Script deiner Meinung nach bescheuert aussieht oder nicht, ist doch wohl egal :-)

neee... das scripten muss ja spaß machen und das get-zeugs würde mich unheimlich nerven :)

Ansonsten muss ich irgendwie doch PEAR mit PHP4.3.x ans laufen bekommen...
im Bezug auf PEAR wird es keinen Unterschied machen ob du PHP4.3.x oder PHP4.4.0 verwendest - oder meinstest du PHP3 (wie im Ursprungsposting)?

ähm, da hab ich mich eher im ursprungsposting verschrieben. vorher war schon php 4.3.x drauf. auf jeden fall ist mir nach der einbindung von pear php in regelmäßigen abständen über unbekannte errors abgeschmiert.

[dedlfix]

echo $begrüßung;

im Bezug auf PEAR wird es keinen Unterschied machen ob du PHP4.3.x oder PHP4.4.0 verwendest

Oh doch. Mit PHP 4.4.0 wurde eine Notice eingeführt, die sich über falsche Verwendung von Referenzen beschwert. Und nicht nur ein PEAR-Paket ist davon betroffen. Wie allerdings der Stand der Reparaturarbeiten insgesamt aussieht habe ich nicht verfolgt.

echo "$verabschiedung $name";

[Tobias Kloth]

Hallo dedlfix,

im Bezug auf PEAR wird es keinen Unterschied machen ob du PHP4.3.x oder PHP4.4.0 verwendest
Oh doch. Mit PHP 4.4.0 wurde eine Notice eingeführt, die sich über falsche Verwendung von Referenzen beschwert.

Ups, danke für den Hinweis - ich glaube aber nicht, dass Stefan das Problem hat, da er ja die Probleme mit der Version vorher hat :-)

Grüße aus Nürnberg
Tobias

[Wilhelm Turtschan]

habe d'ehre

Gibt es denn keinen Parameter in der php.ini der das verhalten zurückstellt?

register_globals auf ON setzen. Mit dem zustaendigen Admin musst Du Dich allerdings selber auseinandersetzen. ;-)

man liest sich
Wilhelm

[Tobias Kloth]

Hallo Stefan,

Wir haben unseren Webserver (mit Apache2) jetzt von PHP 3.irgendwas auf PHP4.4.0 aufgerüstet,

Warum nicht gleich PHP5?

Weiß einer von euch eine Lösung?

verwende das Array $_GET. Bei "datei.php?foo=bar" z.B. enthält $_GET['foo'] den Wert "bar".

Grüße aus Nürnberg
Tobias

[Stefan Welscher]

Hallo Stefan,
Warum nicht gleich PHP5?

Weil ich da auf keine möglichkeit gestoßen bin php_exif.dll zu laden.

Weiß einer von euch eine Lösung?
verwende das Array $_GET. Bei "datei.php?foo=bar" z.B. enthält $_GET['foo'] den Wert "bar".

gnaaa... kann ich das verhalten von oho nicht ändern?
ich hab gerade keine besondere lust all unsere scripte umzuschreiben (und das sind grad nicht wenig). falls das nicht anders geht - was ist die stabilste PHP-version die noch mit normal mit den übergebenen Parametern umgeht?

[Tobias Kloth]

Hallo Stefan,

Weil ich da auf keine möglichkeit gestoßen bin php_exif.dll zu laden.

ähhh... genauso wie bei php4, mit "extension=php_exif.dll" in der php.ini? (Windows, oder?) Ich wüsste nicht, dass sich da was geändert haben sollte ...

gnaaa... kann ich das verhalten von oho nicht ändern?

Doch (wie das geht steht auf der von mir verlinkten Seite) - ich würde aber _dringendst_ davon abraten.

Grüße aus Nürnberg
Tobias

[Stefan Welscher]

ähhh... genauso wie bei php4, mit "extension=php_exif.dll" in der php.ini? (Windows, oder?) Ich wüsste nicht, dass sich da was geändert haben sollte ...

Naja, aber die dll-Datei für PHP4.x hat mit PHP5 nicht mehr funktioniert und ne neue Datei hab ich nirgends gefunden.

Doch (wie das geht steht auf der von mir verlinkten Seite) - ich würde aber _dringendst_ davon abraten.

Danke! Dem Link hab ich verwerflicherweise keine Achtung geschenkt ;)
Ich probier das dann morgen aus. Mir ist aber nicht ganz das Sicherheitsrisiko klar, dass meine config dann darstellt, da ich eben alle sicherheitsrelevanten vars vor der verwendung auf 0 zurücksetze..

[Tobias Kloth]

Hallo Stefan,

Naja, aber die dll-Datei für PHP4.x hat mit PHP5 nicht mehr funktioniert und ne neue Datei hab ich nirgends gefunden.

Bei mir war bei PHP5(.0.4) eine php_exif.dll (mit 57Kb) dabei (im Verzeichnis "ext"), die die bei PHP4(.4.0) dabei war (im Verzeichnis "extensions") hat dagegen nur 52Kb.

Grüße aus Nürnberg
Tobias

PS: die php_mbstring.dll hast du schon mit aktiviert, oder? (siehe http://de2.php.net/exif)

[Stefan Welscher]

Hallo Stefan,

Naja, aber die dll-Datei für PHP4.x hat mit PHP5 nicht mehr funktioniert und ne neue Datei hab ich nirgends gefunden.
Bei mir war bei PHP5(.0.4) eine php_exif.dll (mit 57Kb) dabei (im Verzeichnis "ext"), die die bei PHP4(.4.0) dabei war (im Verzeichnis "extensions") hat dagegen nur 52Kb.

Grüße aus Nürnberg
Tobias

PS: die php_mbstring.dll hast du schon mit aktiviert, oder? (siehe http://de2.php.net/exif)

jo, die hatte ich aktiviert, allerdings gab es bei mir nach der inst. von php 5.0.5 (win über wizard) kein ext-verzeichnis.
drum habe ich dann auch auf die alte dll zurück gegriffen.

ich hab jetzt mal grad register-globals ausprobiert (remote-zugang und cain sei dank ;) ) und funzt fast wieder alles wie geschmiert.
nur scheint es wohl noch ne änderung in rawurlencode gegeben zu haben, weil äüö irgendwie nicht mehr encoded werden. aber das ist erstmal nebensächlich und wird morgen gar beseitigt...