[PHP] Nieuwe PHP 4.2.0

[Verwijderd]

Hallo,

nou op mijn host hebben ze dus omgeschakeld van php 4.1 naar php 4.2 daarin is het een en het ander veranderd. de klant dient dan maar even zijn code aan te passen...

de volgende relevante informatie heb ik gevonden over de aanpassingen:

Interessante nieuwe of gewijzigde functies:
- var_export()
Deze functie werkt als var_dump, echter retourneert deze bruikbare PHP code.

- highlight_string() / highlight_file()
Deze functies hebben een extra flag gekregen zodat ze het resultaat retourneren, in plaats van het naar de browser te sturen. Ideaal voor forums dus!

<?php
$resultaat = highlight_string($forumBericht, TRUE);
?>

- md5_file()
Deze functie retourneerd de MD5 sum van een geheel bestand.

Andere wijzigingen:

Register_Globals op 'off'
-------------------------
De standaard instelling van register_globals is nu 'off'. register_globals is een optie welke je in staat stelt om variabelen welke via GET/POST/COOKIES etc binnen komen te registreren als gewone variabele in de global-scope. Omdat via GET/POST en COOKIES dezelfde variabele namen kunnen binnenkomen kan het voorkomen dat je een stukje onveilige code hiermee schrijft. Om deze reden heeft de PHP Group besloten om de standaard instelling 'off' te maken. Nu gebeurd dit dus NIET meer. De variabelen zijn enkel nog te benaderen via specifieke arrays:

$_GET: Alle variabelen via GET
$_POST: Alle variabelen via POST
$_SERVER: Alle server-specifieke variabelen
$_FILES: Geuploade bestanden
$_ENV: Variabelen uit het environment

<?php

/* Stel dat deze pagina is aangeroepen als /index.php?user=mathieu */

error_reporting(E_ALL);

echo $user . '<br />'; // Dit zal niet meer werken
echo $_GET['user'] . '<br />'; // Dit wel
?>

nou...dus even over die register_globals. wat $_GET doet is dus duidelijk, maar hoe zit het met de andere, wanneer moet je ze wel gebruiken wanneer niet...voorbeelden? ik heb de search al gebruikt en ook al bij google e.d. gekeken, maar kan niks vinden. sowieso stom van mijn host dat ze gelijk gaan updaten i.p.v. het eerst ff af te wachten enzo...

kan iemand hulp bieden?

[Glimi]

Er zijn alleen nieuwe functies aangegeven. Dus je hoeft niets te veranderen lijkt me (op register_globals na)

[Limhes]

Op maandag 10 juni 2002 20:54 schreef Glimi het volgende:
Er zijn alleen nieuwe functies aangegeven. Dus je hoeft niets te veranderen lijkt me (op register_globals na)

Idd. je kan dus geen variabelen direct gebruiken die dmv. een form of querystring doorgegeven worden. Ook omgevingsvariabelen moet je (denk ik) gebruiken dmv. $_ENV ("..."). De 'oude' manieren $HTTP_GET_VARS ed. werken wel nog gewoon dus als je al met register_globals = off werkte werken al je scripts nog.

[Verwijderd]

jah...
er staat dus dat je niet meer kunt doen

PHP:

<? <? echo "$user"; ?> ?>

maar dat moet voortaan zijn

PHP:

<? <? echo "$_GET[user] ?> ?>

maar nu doet dus mijn forum eht niet meer, mijn ledenpagina, mijn registratiepagina, etc. Al mijn php pagina's waar zoveel weken werk in hebben gezeten doen eht niet meer en ik snap toch echt niet wat ik nu moet veranderen enzo...en waar het voor dient...

[Limhes]

Op maandag 10 juni 2002 20:57 schreef monkeymonkeymonkey het volgende:
jah...
er staat dus dat je niet meer kunt doen

PHP:

<? <? echo "$user"; ?> ?>

maar dat moet voortaan zijn

PHP:

<? <? echo "$_GET[user] ?> ?>

maar nu doet dus mijn forum eht niet meer, mijn ledenpagina, mijn registratiepagina, etc. Al mijn php pagina's waar zoveel weken werk in hebben gezeten doen eht niet meer en ik snap toch echt niet wat ik nu moet veranderen enzo...en waar het voor dient...

En register_globals kan niet op on worden gezet?

[ACM]

Alles wat door GET methoden wordt meegegeven moet je door $_GET['naam'] vervangen.
Alles wat met POST ... etc

En wil je weten waar wat fout gaat ->
error_reporting(E_ALL) aanzetten.

Ook zijn er wel methodes genoemd om, ondanks de globals die uitstaan ze toch te 'zetten'.

[Verwijderd]

nee dat wil de host dus niet...om de een of andere vage reden...maar misschien heb ik het fout maar als je register_globals op on zet dan werken ze toch allebei?
dan kun je toch $user gebruiken maar ook $_GET[user] als dat iig het geval is dan zie ik het probleem niet...zet het op on...iedereen blij...alle code werkt!

[Glimi]

Op maandag 10 juni 2002 21:00 schreef Limhes het volgende:

[..]

En register_globals kan niet op on worden gezet?

90% zeker dat die host in safe_mode draait. En dat mag ook wel met users die standaar zut als $var gaan gebruiken

[Verwijderd]

Op maandag 10 juni 2002 21:01 schreef Glimi het volgende:

[..]

90% zeker dat die host in safe_mode draait. En dat mag ook wel met users die standaar zut als $var gaan gebruiken

waarom dat nou weer? wat zit hij er nou weer mee als van die sufferds $var gebruiken?¿? als hij toch zelf lekker die global_variables gebruikt...en daarbij...eerst was dat ook niet...en de mogelijk wás er wel...nu staat het standaar op "on" en dan is't van laat maar aanstaan?

[Limhes]

Op maandag 10 juni 2002 21:01 schreef Glimi het volgende:

[..]

90% zeker dat die host in safe_mode draait. En dat mag ook wel met users die standaar zut als $var gaan gebruiken

Ja zou ik ook doen als ik host was, maar het zou kunnen dat hij een eigen servertje heeft ergens waar de php install alleen voor hem is. Dan zou het wel veranderd kunnen worden nl.

[Verwijderd]

Op maandag 10 juni 2002 21:04 schreef Limhes het volgende:

[..]

Ja zou ik ook doen als ik host was, maar het zou kunnen dat hij een eigen servertje heeft ergens waar de php install alleen voor hem is. Dan zou het wel veranderd kunnen worden nl.

jah maar dat bedoel ik nou juist...alsie op off staat kun je toch nog veilig doen door $_GET te gebruiken of heb'k het nou mis?

[Glimi]

Op maandag 10 juni 2002 21:03 schreef monkeymonkeymonkey het volgende:
waarom dat nou weer? wat zit hij er nou weer mee als van die sufferds $var gebruiken?¿?

Normale vraagtekens, en in aantal 1 begrijp ik ook. Ik kan echt heel goed bedenken waarom die man ervoor kiest om de safe-mode aan te zetten.
• Als een klant gehackt is, is ie niet blij en gaat ie andere mensen de schuld geven.
• Een gehackte account is een ingang op die machine en een possible root compromise

als hij toch zelf lekker die global_variables gebruikt...en daarbij...eerst was dat ook niet...en de mogelijk wás er wel...nu staat het standaar op "on" en dan is't van laat maar aanstaan?

Nee. Nu zijn er redelijke alternatieven ipv standaard Not Global HTTP_GET_VARS ed. BTW jij bent degene die die globalized vars nog gebruikt en niet de auto global array's

[Dennis]

Nee, geen $_GET[user] maar $_GET['user']

[Verwijderd]

Op maandag 10 juni 2002 21:17 schreef ddc het volgende:
Nee, geen $_GET[user] maar $_GET['user']

wijsneus

[wietco]

En als je geen zin hebt om je code te veranderen dan kan je toch gewoon dit gebruiken?

code:

while(list($key,$value) = each($_GET)){
 $key = $value;
}

[Verwijderd]

Op maandag 10 juni 2002 22:06 schreef wietco het volgende:
En als je geen zin hebt om je code te veranderen dan kan je toch gewoon dit gebruiken?

code:

while(list($key,$value) = each($_GET)){
 $key = $value;
}

en voor $_POST dan enzo? en daar komt dan bij dat ik met dat hele global variables er niks meer van snap...ik weet niet meer wanneer ik wat moet gebruiken

[wietco]

voor $_POST lijkt het me hetzelfde als het ook een array is maar dat weet ik niet zeker omdat ik er zelf ook niet echt in thuis ben die while leek met gewoon wel logish

[martinvw]

als je een Formulier met POST gebruikt dan komen de variabele terecht in $_POST[] als je een formulier met GET gebruikt om variabele via de url te posten $_GET

Cookie vars zitten in $_COOKIE[] en Sesion vars in $_SESSION[] en ja zo maar door.

[Glimi]

Op maandag 10 juni 2002 22:06 schreef wietco het volgende:
En als je geen zin hebt om je code te veranderen dan kan je toch gewoon dit gebruiken?

code:

while(list($key,$value) = each($_GET)){
 $key = $value;
}

En daarmee is het wederom mogelijk om elke variabele binnen het script of in de session fijn te overschrijven met een get

[ACM]

maar goed, dit is al eerder behandeld en verder vrij triviaal allemaal.