Onderwerp: register_globals

Ik moet bekennen dat ik in het verleden niet altijd netjes de variabelen met
$var=$_POST['var'] heb opgehaald. Behalve onervarenheid werd het ook niet
aangemoedigd omdat register_globals op de server standaard op 'On' stond.

Nu heeft de hosting provider aangekondigd dat ze binnenkort register_globals
op 'Off' zetten.
Bij in ieder geval één oude site geeft dat veel problemen: niet alleen om
het in alle scripts aan te passen, maar met name om alles te testen.

Het is een Win-server, dus met .htaccess kan ik de server default niet
wijzigen. Wel zou ik het met (php) extract($_POST); op kunnen lossen, maar
de kans bestaat dat de host dat ook blokkeert.

Hebben anderen dit probleem ook?
In hoeverre is het reeël om de kosten voor de hersteloperatie door te
berekenen aan de klant? Ik heb ze nooit hostingkosten in rekening gebracht
(ze betalen rechtstreeks aan de provider)

--
Nico Schuyt
http://www.nicoschuyt.nl/

Nico Schuyt:

> Nu heeft de hosting provider aangekondigd dat ze binnenkort register_globals
> op 'Off' zetten.

Dat is op zich al netjes. Je zult de hosters de kost moeten geven, die
het gewoon onaangekondigd doen.

> Bij in ieder geval één oude site geeft dat veel problemen: niet alleen om
> het in alle scripts aan te passen, maar met name om alles te testen.

Het is prima dat je vooral dat testen nu reeds als omvangrijke aktiviteit
identificeert. Ik krijg te vaak bij wijzigingen te horen: "Klaar? OK, zet
maar online.
Huh? Testen? Moet dat ook?"

>
> Wel zou ik het met (php) extract($_POST); op kunnen lossen, maar
> de kans bestaat dat de host dat ook blokkeert.

Waaruit leid je af dat die kans bestaat (en kennelijk aanzienlijk is)?
Ik heb tot nu toe geen hoster gezien die dat verbiedt.

Het alternatief is om een include-stukje te bakken waarin je de extract()
min of meer handmatig uitvoert:
foreach ($_POST as $key=>$value) {$$key = $value;}
....en dat include-stukje overal opneemt.

(even uit het hoofd en met een wijntje op, dus wellicht voor verbetering
vatbaar)

> Hebben anderen dit probleem ook?
> In hoeverre is het reeël om de kosten voor de hersteloperatie door te
> berekenen aan de klant? Ik heb ze nooit hostingkosten in rekening gebracht
> (ze betalen rechtstreeks aan de provider)

Als de site in de tijd van $HTTP_POST_VARS is gemaakt en goed heeft
gefunctioneerd, is adaptief onderhoud naar mijn idee - naar eer en
geweten - doorbelastbaar. Een klant beseft best dat de technische
ontwikkelingen niet stilstaan, en dat de horizon waarbinnen je die
ontwikkelingen kunt voorzien beperkt is.

Bovendien is de inspanning, wanneer bovengenoemd maniertje werkt, niet
bijster groot qua bouw. Over het benodigde testwerk en de risico's van
steekproefsgewijze test kun je praten.



--
Erick

"Die MM-scripts zijn write-only" - Ronald Klip in niwo

Erick T. Barkhuis wrote:
> Nico Schuyt:

>> Nu heeft de hosting provider aangekondigd dat ze binnenkort
>> register_globals op 'Off' zetten.

> Dat is op zich al netjes. Je zult de hosters de kost moeten geven, die
> het gewoon onaangekondigd doen.

>> Bij in ieder geval één oude site geeft dat veel problemen: niet
>> alleen om het in alle scripts aan te passen, maar met name om alles
>> te testen.

> Het is prima dat je vooral dat testen nu reeds als omvangrijke
> aktiviteit identificeert. Ik krijg te vaak bij wijzigingen te horen:
> "Klaar? OK, zet maar online.
> Huh? Testen? Moet dat ook?"

>> Wel zou ik het met (php) extract($_POST); op kunnen lossen, maar
>> de kans bestaat dat de host dat ook blokkeert.

> Waaruit leid je af dat die kans bestaat (en kennelijk aanzienlijk is)?
> Ik heb tot nu toe geen hoster gezien die dat verbiedt.

De mate van waarschijnlijkheid kan ik niet goed uitsluiten. De betreffende
helpdesk sloot het niet uit; ik kan me voorstellen dat als die extract()
dezelfde risico´s met zich meebrengt als de register_globals 'On' (Of zie ik
dat verkeerd?)

> Het alternatief is om een include-stukje te bakken waarin je de
> extract() min of meer handmatig uitvoert:
> foreach ($_POST as $key=>$value) {$$key = $value;}
> ...en dat include-stukje overal opneemt.
> (even uit het hoofd en met een wijntje op, dus wellicht voor
> verbetering vatbaar)

Ik zal het (inmiddels zelf mijn 3e wijntje gehad) pas morgen uitproberen :-)

>> Hebben anderen dit probleem ook?
>> In hoeverre is het reeël om de kosten voor de hersteloperatie door te
>> berekenen aan de klant? Ik heb ze nooit hostingkosten in rekening
>> gebracht (ze betalen rechtstreeks aan de provider)

> Als de site in de tijd van $HTTP_POST_VARS is gemaakt en goed heeft
> gefunctioneerd, is adaptief onderhoud naar mijn idee - naar eer en
> geweten - doorbelastbaar. Een klant beseft best dat de technische
> ontwikkelingen niet stilstaan, en dat de horizon waarbinnen je die
> ontwikkelingen kunt voorzien beperkt is.
> Bovendien is de inspanning, wanneer bovengenoemd maniertje werkt, niet
> bijster groot qua bouw. Over het benodigde testwerk en de risico's van
> steekproefsgewijze test kun je praten.

Bedankt Erick!

--
Nico Schuyt
http://www.nicoschuyt.nl/

Nico Schuyt wrote:
> Erick T. Barkhuis wrote:
>> Nico Schuyt:

>>> Wel zou ik het met (php) extract($_POST); op kunnen lossen, maar
>>> de kans bestaat dat de host dat ook blokkeert.

>> Waaruit leid je af dat die kans bestaat (en kennelijk aanzienlijk
>> is)? Ik heb tot nu toe geen hoster gezien die dat verbiedt.

> De mate van waarschijnlijkheid kan ik niet goed uitsluiten. De
> betreffende helpdesk sloot het niet uit; ik kan me voorstellen dat
> als die extract() dezelfde risico´s met zich meebrengt als de
> register_globals 'On' (Of zie ik dat verkeerd?)

Hmmm, als ik dat overlees, is dat 3e wijntje toch wat teveel van het goede
geweest.

--
Nico Schuyt
http://www.nicoschuyt.nl/

Nico Schuyt:
> Nico Schuyt wrote:
> > Erick T. Barkhuis wrote:
> >> Nico Schuyt:
>
> >>> Wel zou ik het met (php) extract($_POST); op kunnen lossen, maar
> >>> de kans bestaat dat de host dat ook blokkeert.
>
> >> Waaruit leid je af dat die kans bestaat (en kennelijk aanzienlijk
> >> is)? Ik heb tot nu toe geen hoster gezien die dat verbiedt.
>
> > De mate van waarschijnlijkheid kan ik niet goed uitsluiten. De
> > betreffende helpdesk sloot het niet uit; ik kan me voorstellen dat
> > als die extract() dezelfde risico´s met zich meebrengt als de
> > register_globals 'On' (Of zie ik dat verkeerd?)
>
> Hmmm, als ik dat overlees, is dat 3e wijntje toch wat teveel van het goede
> geweest.

Neem er nog eentje, zet je PC uit, doe dat in omgekeerde volgorde, en
laat de boel rusten. :-)

Anyway, het gevaar van het automatisch omzetten van de $_POST-array naar
afzonderlijke variabelen is, dat er wel eens heel specifieke key-waardes
tussen zouden kunnen zitten. Key-waardes die, eenmaal omgezet,
belangrijke (systeem)variabelen zouden kunnen overschrijven.
Een slimme mogelijkheid om dat te voorkomen zit al in extract(), namelijk
de toevoeging - collission flag - EXTR_PREFIX_SKIP.

Diezelfde functionaliteit kun je in mijn zelfgebakken extract()-functie
ook gemakkelijk inbouwen - handig ingeval de hoster 'extract()' verbiedt:

foreach ($_POST as $key=>$value) {$$key = $value;}

wordt dan:

foreach ($_POST as $key=>$value) {
if (!isset($$key)) {$$key = $value;}
}

[Opnieuw met de wijndisclaimer, uiteraard]



--
Erick

Nico Schuyt wrote:
> Nico Schuyt wrote:
>> Erick T. Barkhuis wrote:
>>> Nico Schuyt:
>
>>>> Wel zou ik het met (php) extract($_POST); op kunnen lossen, maar
>>>> de kans bestaat dat de host dat ook blokkeert.
>
>>> Waaruit leid je af dat die kans bestaat (en kennelijk aanzienlijk
>>> is)? Ik heb tot nu toe geen hoster gezien die dat verbiedt.
>
>> De mate van waarschijnlijkheid kan ik niet goed uitsluiten. De
>> betreffende helpdesk sloot het niet uit; ik kan me voorstellen dat
>> als die extract() dezelfde risico´s met zich meebrengt als de
>> register_globals 'On' (Of zie ik dat verkeerd?)
>
> Hmmm, als ik dat overlees, is dat 3e wijntje toch wat teveel van het
> goede geweest.

Extract() wordt so goed als nooit geblokkeerd, en het is zo goed als niet
te doen om te controleren welke array er in extract wordt gegooid, terwijl
die functie af en toe erg handig is.

Waarschijnlijk kun je dus gewoon extract($_POST); (of direct
(extract($_REQUEST)) gebruiken, maar ik zou toch wel willen aanraden dit
soort variabelen van buitenaf altijd grondig te controleren... Er zijn toch
heel wat sites waar ik rare dingen zou kunnen uithalen, tot databases
leeghalen aan toe, mocht ik dat willen.
--
Rik Wasmus

Rik wrote:
>>>> Nico Schuyt:

>>>>> Wel zou ik het met (php) extract($_POST); op kunnen lossen, maar
>>>>> de kans bestaat dat de host dat ook blokkeert.

> Extract() wordt so goed als nooit geblokkeerd, en het is zo goed als
> niet te doen om te controleren welke array er in extract wordt
> gegooid, terwijl die functie af en toe erg handig is.
>
> Waarschijnlijk kun je dus gewoon extract($_POST);
> (of direct
> (extract($_REQUEST)) gebruiken,

Dat is een efficiente! Bedankt.

> maar ik zou toch wel willen aanraden
> dit soort variabelen van buitenaf altijd grondig te controleren... Er
> zijn toch heel wat sites waar ik rare dingen zou kunnen uithalen, tot
> databases leeghalen aan toe, mocht ik dat willen.

Heel verontrustend.

--
Nico Schuyt
http://www.nicoschuyt.nl/

Erick T. Barkhuis wrote:
> Nico Schuyt:

[knip wartaal]

>> Hmmm, als ik dat overlees, is dat 3e wijntje toch wat teveel van het
>> goede geweest.

> Neem er nog eentje, zet je PC uit, doe dat in omgekeerde volgorde, en
> laat de boel rusten. :-)

Heb ik gedaan. Vanmorgen hoofdpijn. Weet niet zeker of dat van de wijn komt
of de afkickverschijnselen na uitzetten van de PC.

> Anyway, het gevaar van het automatisch omzetten van de $_POST-array
> naar afzonderlijke variabelen is, dat er wel eens heel specifieke
> key-waardes tussen zouden kunnen zitten. Key-waardes die, eenmaal
> omgezet, belangrijke (systeem)variabelen zouden kunnen overschrijven.
> Een slimme mogelijkheid om dat te voorkomen zit al in extract(),
> namelijk de toevoeging - collission flag - EXTR_PREFIX_SKIP.

Is nieuw voor me. Het verbaast me overigens dat die parameter niet genoemd
wordt in http://nl3.php.net/manual/nl/function.extract.php
(wel in bijv. http://www.phpdig.net/ref/rn03re44.html)

> Diezelfde functionaliteit kun je in mijn zelfgebakken
> extract()-functie ook gemakkelijk inbouwen - handig ingeval de hoster
> 'extract()' verbiedt:
> foreach ($_POST as $key=>$value) {$$key = $value;}
> wordt dan:
> foreach ($_POST as $key=>$value) {
> if (!isset($$key)) {$$key = $value;}
> }
> [Opnieuw met de wijndisclaimer, uiteraard]

Werkt uitstekend. Nogmaals dank.

--
Nico Schuyt
http://www.nicoschuyt.nl/

Nico Schuyt:
> Erick T. Barkhuis wrote:

> > Een slimme mogelijkheid om dat te voorkomen zit al in extract(),
> > namelijk de toevoeging - collission flag - EXTR_PREFIX_SKIP.
>
> Is nieuw voor me. Het verbaast me overigens dat die parameter niet genoemd
> wordt in http://nl3.php.net/manual/nl/function.extract.php
> (wel in bijv. http://www.phpdig.net/ref/rn03re44.html)

Hm, tsja, bij nader inzien lijkt me EXTR_SKIP mooi zat, en snap ik zelf
niet goed waarom phpdig zich om een prefix zou bekommeren als er toch al
wordt geskipt.

Wellicht is het bij tegenstrijdigheden beter de adviezen van de
'officiele' PHP-Manual te hanteren dan af te gaan op andere bronnen.

--
Erick