[PHP] Zelfde script op 2 servers

[Verwijderd]

Ik heb hetzelfde script op 2 servers gezet:

http://fst.facturez.be/scripting/jarno.php
en
http://jarno.no-ip.com/php/jarno.php

Op mijn eige server (jarno.no-ip.com) genereerd hij echter een domme fout op lijn 8:
$jarno = $_POST['jarno'];

Hoe komt dat FST dit negeerd?
Volgens mij heeft dit met een instelling te maken in PHP...
Iets waardoor mijn eige server fouten ziet in undefined var's...
Hoe krijg ik deze instelling goed?

De PHP-versies staan hier:
http://fst.facturez.be/scripting/dingetje.php
en
http://jarno.no-ip.com/php/phpinfo.php

Kan er iemand mij helpen?

[Speedener]

op de ene server staat in de php.ini dat hij alle fouten, waarschuwingen en zo moet laten zien (E_ALL)

en ik denk dat de andere alleen fouten laat zien (E_ERROR)

[Verwijderd]

Speedener schreef op 15 februari 2004 @ 17:34:
op de ene server staat in de php.ini dat hij alle fouten, waarschuwingen en zo moet laten zien (E_ALL)

en ik denk dat de andere alleen fouten laat zien (E_ERROR)

HM, genoteerd.
Zie je nog iets wat een serieus verschil kan zijn?

[gorgi_19]

Staat hier niets tussen? ?

[GlowMouse]

register_globals aan, en register_globals uit

[KompjoeFriek]

op de ene server staat global vars aan en op de andere niet?

[Verwijderd]

GlowMouse schreef op 15 februari 2004 @ 17:37:
register_globals aan, en register_globals uit

Jep, dat isem. Bedankt jongens

[Robinski]

misschien handig om eerst met isset() te testen of variabele bestaat / geset is?

[Buzzin Hornet]

en

code:

$jarno = $_POST['jarno'];

Kan je beter vervangen voor

code:

extract($_POST);

Dan maakt die alle variabelen in de array normaal.

Daarnaast is het inderdaad Globals die uit en aan staan maar dat wist je al

[GlowMouse]

Buzzin Hornet schreef op 15 februari 2004 @ 17:45:

code:

extract($_POST);

Dan maakt die alle variabelen in de array normaal.

Daarmee wordt het hele voordeel van register_globals off teniet gedaan. Register_globals staat standaard uit om veel veiligheidsproblemen te voorkomen.

[Verwijderd]

GlowMouse schreef op 15 februari 2004 @ 17:47:
Daarmee wordt het hele voordeel van register_globals off teniet gedaan. Register_globals staat standaard uit om veel veiligheidsproblemen te voorkomen.

Da's natuurlijk niet waar. Als je de $_POST variabelen extract, wil dat nog niet zeggen dat de $_GET variabelen (bijvoorbeeld) ook 'korter' zijn gemaakt. Register_globals Off in combinatie met extract werkt gewoon veilig.

[Verwijderd]

Verwijderd schreef op 15 februari 2004 @ 18:03:
[...]
Register_globals Off in combinatie met extract werkt gewoon veilig.

En... Waarom dan wel?

[PrisonerOfPain]

Verwijderd schreef op 15 februari 2004 @ 20:06:
[...]

En... Waarom dan wel?

Omdat extract bij dezelfde variabele de reeds bestaande var niet overschrijft en register_globals on doet dat wel

[Bosmonster]

Ook handig om er direct een trim-actie aan te hangen:

extract (array_map("trim", $_POST));

Omdat extract bij dezelfde variabele de reeds bestaande var niet overschrijft en register_globals on doet dat wel

Hoe kan register_globals nu variabelen overschrijven als deze ze altijd als eerste aanmaakt? Oftewel op het moment dat deze standaard variabelen aanmaakt bestaan er nog geen anderen.

Veiligheid is een probleem, maar imho veel belangrijker is code-leesbaarheid. Het is voor een programmeur onleesbaar als die code van een ander moet lezen en overal ineens variabelen gebruikt worden die uit het niets komen.

Ander probleem is dat er geen onderscheid meer wordt gemaakt tussen SESSION/COOKIE/GET/POST/ETC variabelen... Het wordt een grote puinhoop dus. Leesbaar misschien voor degene die het schrijft, maar een ramp voor anderen die code aan moeten passen later.

[ Voor 135% gewijzigd door Bosmonster op 16-02-2004 10:37 ]

[Verwijderd]

GlowMouse schreef op 15 februari 2004 @ 17:37:
register_globals aan, en register_globals uit

Hier heeft et niks mee te maken -> heb in de ini dit aangezet, maar nog lukt het niet. Hoe komt dit dan wel?
Moet ik het hele ini gaan aanpassen en die zoals op FST maken voor 1 dom ding?
Is er geen makkelijkere oplossing?

[Suepahfly]

Nee Jarno is niet slim


Maare om je probleemje te verhelpen:
Eerst $jarno initialiseren ($jarno ="")

Of even een ini_set() doen
Of een error_reporting() doen.

De exacte waarde die je mee moet geven kan je vinden op php.net

[Anders]

Vond het al zo vreemd dat register_globals er mee te maken zou hebben. Dat zou immers geen error op

PHP:

$jarno = $_POST['jarno'];

kunnen genereren. Het ligt gewoon aan de error-reporting. Die staat op "hoog" waardoor alle kleinigheden op je scherm worden geschreven. In jouw geval krijg je dus een error op deze regel omdat $_POST['jarno'] niet bestaat. Als ik dit formulier submit:

code:

<FORM METHOD=post ACTION="http://jarno.no-ip.com/php/jarno.php">
<INPUT NAME=jarno>
</FORM>

.. verschijnt die notice niet meer: $_POST['jarno'] bestaat dan immers wel.

Als je de .ini niet aan wilt/kunt passen, kun je die notices onderdrukken door bovenaan je pagina het volgende op te nemen:

PHP:

error_reporting(E_ALL ^ E_NOTICE);

Zie: http://nl3.php.net/error_reporting

[Verwijderd]

Anders schreef op 16 februari 2004 @ 18:21:
Het ligt gewoon aan de error-reporting. Die staat op "hoog" waardoor alle kleinigheden op je scherm worden geschreven.

Hoe zet ik die lager?
Bij mijn eigen server staat die op E_ALL. Maar bij die van FST staat er een nummer: 2039???
Wat moet ik nu doen?

[Anders]

Staat onderaan mijn post:

PHP:

error_reporting(E_ALL ^ E_NOTICE);

toevoegen bovenaan je pagina's. Dit toont alle errors behalve de notices.

[stekkel]

Als je jezelf slordig php programmeren wilt aanleren moet je vooral error_reporting van E_ALL afhalen.

[Anders]

En als je je bezoekers regelmatig op notices wilt tracteren, moet je het vooral aan laten staan.

In 9 van de 10 gevallen is bv. het niet vooraf definiëren van een variabele niet kritiek. In de gevallen waar het wel kritiek is, vang je het af met een check die de gebruiker een nette melding voorspiegelt ipv een botte, onbegrijpelijke notice. Ik snap best dat het - om PHP te leren - handig kan zijn om de E_NOTICE aan te zetten, maar ik vind dat de programmeer-puristen het belang ervan behoorlijk overdrijven. Het doet me denken aan de HTML-puristen die je al jarenlang met de W3-specs om de oren meppen als je het waagt om tabellen te gebruiken voor lay-out.

[djluc]

Het zorgt gewoon voor duidelijkere code, en het is echt wel aan te raden Anders. Je zult toch alle user input moeten valideren dus het maakt niet zoveel uit of je even controleerd of de var wel bestaat.

[Erkens]

Anders schreef op 16 februari 2004 @ 19:55:
En als je je bezoekers regelmatig op notices wilt tracteren, moet je het vooral aan laten staan.

als het goed is gebeurd dat niet, tenzij je online zit te devven
overigens (als ik zelf deze messages niet afvang) zet ik in een productieomgeving error_reporting gewoon uit, immers de applicatie is volledig debugged, maar zelf vang ik de errors liever zelf af

In 9 van de 10 gevallen is bv. het niet vooraf definiëren van een variabele niet kritiek. In de gevallen waar het wel kritiek is, vang je het af met een check die de gebruiker een nette melding voorspiegelt ipv een botte, onbegrijpelijke notice. Ik snap best dat het - om PHP te leren - handig kan zijn om de E_NOTICE aan te zetten, maar ik vind dat de programmeer-puristen het belang ervan behoorlijk overdrijven. Het doet me denken aan de HTML-puristen die je al jarenlang met de W3-specs om de oren meppen als je het waagt om tabellen te gebruiken voor lay-out.

mja, programmeer-purist wil ik me niet noemen, maar variabelen gebruiken die er niet zijn is gewoon dom

[Anders]

Niet per sé.

Neem een formulier dat niet door je validatie heenkomt, en dat je weer aan de gebruiker toont met de vraag de gegevens te verbeteren. Die zou je als volgt kunnen opbouwen:

code:

<FORM METHOD="GET">
<INPUT 
   TYPE="text" 
   NAME="voornaam" 
   MAXLENGTH="20"
   VALUE="<?=htmlspecialchars($_GET["voornaam"])?>">
</FORM>

.. waardoor je dezelfde code zowel kunt gebruiken voor het initiële formulier (waarin $_GET leeg is), als voor het formulier dat je toont als je niet door de validatie heenkomt. Minder code voor dezelfde functionaliteit. Aangezien je altijd nog een validatie achter de hand hebt, lijkt dit me geen security risk. Natuurlijk kan het netter, groter, vollediger, maar je hebt nou eenmaal niet altijd alle tijd van de wereld.

[stekkel]

zoveel moeite is initialiseren echt niet hoor.

PHP:

<?php
$voornaam = (isset($_POST['voornaam'])) ? $_POST['voornaam'] : '';
?>
<FORM METHOD="POST">
<INPUT 
   TYPE="text" 
   NAME="voornaam" 
   MAXLENGTH="20"
   VALUE="<? htmlspecialchars($voornaam)?>">
</FORM>

maar goed ik zal wel een php purist zijn

[ Voor 22% gewijzigd door stekkel op 17-02-2004 00:13 ]

[X-Lars]

ik ben het toch wel met stekkel eens. het is een kleine moeite je dit aan te leren en wat nou als je soms, zoals ik dus , op een (andere) server werkt waarop error_reporting 'hoog' staat (en deze niet zomaar aan kunt passen) en je scripts van jezelf (gedeeltelijk) kopieert? moet je weer zo'n boel aanpassen.. als je het op 'correcte' wijze doet, kun je die problemen niet krijgen en hoef je er ook niet aan te denken/jezelf iets anders aan te leren. en syntactisch hoort het eigenlijk ook gewoon zo, variabelen moeten er wel zijn voor je er wat mee kunt.

edit: wel beetje offtopic trouwens

[ Voor 7% gewijzigd door X-Lars op 17-02-2004 14:00 ]