/ Forside / Teknologi / Udvikling / PHP / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
PHP
#NavnPoint
rfh 3959
natmaden 3372
poul_from 3310
funbreak 2700
stone47 2230
Jin2k 1960
Angband 1743
Bjerner 1249
refi 1185
10  Interkril.. 1146
"Undefined variable"
Fra : Brian Danielsen


Dato : 13-03-06 18:14

Hej med jer.

jeg er gået igang med en PHP bog, og der står følgende kode.

------orderform.html------
<form action="processorder.php" method=post>
   <table border="0">
      <tr bgcolor="#cccccc">
         <td width="150">Item</td>
         <td width="15">Quantity</td>
      </tr>
      <tr>
         <td>tires</td>
         <td align="center"><input type="text" name="tireqty" size="3"
maxlength="3"></td>
      </tr>
      <tr>
         <td>Oil</td>
         <td align="center"><input type="text" name="oilqty" size="3"
maxlength="3"></td>
      </tr>
         <tr>
         <td>Spark Plugs</td>
         <td align="center"><input type="text" name="sparkqty" size="3"
maxlength="3"></td>
      </tr>
      <tr>
         <td colspan="2" align="center"><input type="submit"
value="Submit Order"></td>
      </tr>
   </table>
</form>
---------------------------------------

og php filen....

--------processorder.php----------
<html>
<head>
   <title>Auto Parts</title>
</head>
<body>
<h1>Autoparts</h1>
<h2>Order Results</h2>
<?
   echo "<p>Order processed at ";
   echo date("H:i, jS F");
   echo "<br />";
   echo "<p>Your order is as follows:";
   echo "<br />";
   echo $tireqty. "tires<br />";
   echo $oilqty. "bottles of oil<br />";
   echo $sparkqty. "spark plugs<br />";
?>
</body>
</html>
----------------------------------------
min output er således ud:

Autoparts
Order Results

Order processed at 18:05, 13th March

Your order is as follows:

Notice: Undefined variable: tireqty in
c:\Inetpub\wwwroot\php\processorder.php on line 14
tires

Notice: Undefined variable: oilqty in
c:\Inetpub\wwwroot\php\processorder.php on line 15
bottles of oil

Notice: Undefined variable: sparkqty in
c:\Inetpub\wwwroot\php\processorder.php on line 16
spark plugs

har dobbelt dobbelt dobbelt dobbelt tjekket og kan bare ikke se
hvad der er galt....

det skal siges at bogen er om PHP4 og jeg har installeret PHP5
-kan det have noget med det at gøre?

håber på at få et hurtigtsvar

venlig hilsen, og på forhånd tak
Brian Danielsen

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

 
 
Jacob Atzen (13-03-2006)
Kommentar
Fra : Jacob Atzen


Dato : 13-03-06 18:22

On 2006-03-13, Brian Danielsen <brian.v.danielsen@gmail.com> wrote:
> Hej med jer.
>
> jeg er gået igang med en PHP bog, og der står følgende kode.

Jeg vil råde dig til hurtigst muligt at finde dig en bedre bog. Den du
har fat i forudsætter tilsyneladende at register_globals er slået til,
hvilket er en stor no-no! Må jeg være så fræk og spørge, hvilken bog der
er tale om?

[snip]
> og php filen....

[snip]
>    echo $sparkqty. "spark plugs<br />";

[snip]
> min output er således ud:

[snip]
> Notice: Undefined variable: sparkqty in
> c:\Inetpub\wwwroot\php\processorder.php on line 16
> spark plugs
>
> har dobbelt dobbelt dobbelt dobbelt tjekket og kan bare ikke se
> hvad der er galt....

Prøv med følgende:

echo $_POST['sparkqty']." spark plugs<br />";

Og så fremdeles.

Når register_globals er slået fra (hvilket det bør være!) bliver
variable ikke automatisk initialiseret udelukkende baseret på navn. Du
kan alternativt til $_POST[] bruge $_REQUEST[], hvis du vil kunne
håndtere både post og get requests med samme kode.

--
Med venlig hilsen
- Jacob Atzen

Mads Lie Jensen (13-03-2006)
Kommentar
Fra : Mads Lie Jensen


Dato : 13-03-06 21:17

On 13 Mar 2006 17:21:35 GMT, Jacob Atzen <jacob@aub.dk> wrote:

>> jeg er gået igang med en PHP bog, og der står følgende kode.
>
>Jeg vil råde dig til hurtigst muligt at finde dig en bedre bog. Den du
>har fat i forudsætter tilsyneladende at register_globals er slået til,
>hvilket er en stor no-no! Må jeg være så fræk og spørge, hvilken bog der
>er tale om?

Så er det vel heller ikke værre? Register_globals er ikke i sig selv
farligt. Det er først farligt når man ikke er opmærksom på hvad man
laver - hvilket en nybegynder sikkert ikke er.
Men derfor kan bogen jo være fin nok. Og sikkert af ældre dato.

Når så php er sat op til at komme med notices når man bruger variable
uden at de er initialiseret, så er det ikke helt slemt.

--
Mads Lie Jensen - mads@gartneriet.dk - ICQ #25478403

Gartneriet - nu ny indpakning (delvist i hvert fald): http://www.gartneriet.dk/

Jacob Atzen (13-03-2006)
Kommentar
Fra : Jacob Atzen


Dato : 13-03-06 21:45

On 2006-03-13, Mads Lie Jensen <mads@gartneriet.dk> wrote:
> Så er det vel heller ikke værre? Register_globals er ikke i sig selv
> farligt. Det er først farligt når man ikke er opmærksom på hvad man
> laver - hvilket en nybegynder sikkert ikke er.

Hvorfor det ikke hører hjemme i en bog som tilsyneladende er rettet mod
begyndere.

Jeg har endnu til gode at høre et godt argument for register_globals.
Hvis du har nogen er jeg meget nysgerrig. Jeg kan umiddelbart komme på
følgende argumenter mod brugen af register_globals:

- Sikkerhedshul. Hvis man ikke er meget påpasselig giver man angribere
en potentiel angrebsvektor.
- Læsbarhed. Koden bliver betydeligt sværere at læse når man ikke
eksplicit bliver gjort opmærksom på hvor indholdet af variable stammer
fra.

> Men derfor kan bogen jo være fin nok. Og sikkert af ældre dato.

Formentlig, register_globals blev ændret til at være slået fra som
standard i PHP 4.2.0, der blev frigivet 22/4 2002[1]. Og ja, bogen kan
være fin nok, men når man fra forfatterens side forudsætter
register_globals tvivler jeg bare på kvaliteten af resten.

> Når så php er sat op til at komme med notices når man bruger variable
> uden at de er initialiseret, så er det ikke helt slemt.

Det kræver man er sikker på at alle kritiske variable _altid_ er
initialiseret korrekt, ligegyldigt hvilken sti igennem koden man har
taget. Igen, jeg har svært ved at se nogen argumenter for, at man vil
ønske at skulle foretage den slags kodeanalyse.

[1]: <http://dk.php.net/ChangeLog-4.php#4.2.0>

--
Med venlig hilsen
- Jacob Atzen

Peter Brodersen (13-03-2006)
Kommentar
Fra : Peter Brodersen


Dato : 13-03-06 23:06

On 13 Mar 2006 20:44:52 GMT, Jacob Atzen <jacob@aub.dk> wrote:

>Jeg kan umiddelbart komme på
>følgende argumenter mod brugen af register_globals:

- Kompatibilitet. I PHP 6.0 dør register_globals fuldstændigt, og så
er der næppe et centralt sted at enable det:
http://www.php.net/~derick/meeting-notes.html#register-globals

--
- Peter Brodersen
Find dig selv: http://map.ter.dk/

Bertel Lund Hansen (13-03-2006)
Kommentar
Fra : Bertel Lund Hansen


Dato : 13-03-06 18:31

Brian Danielsen skrev:

> jeg er gået igang med en PHP bog, og der står følgende kode.

Jeg tilslutter mig Jakob Atzens svar, men det er ikke så svært at
rette op på kalamiteten i dit eksempel:

> --------processorder.php----------
> <html>
> <head>
>    <title>Auto Parts</title>
> </head>
> <body>
> <h1>Autoparts</h1>
> <h2>Order Results</h2>
> <?
$tireqty=$POST['tireqty'];
$oilqty=$POST['oilqty'];
$sparkqty=$POST['sparkqty'];

// herefter vil det virke som tænkt.

>    echo "<p>Order processed at ";
>    echo date("H:i, jS F");
>    echo "<br />";
>    echo "<p>Your order is as follows:";
>    echo "<br />";
>    echo $tireqty. "tires<br />";
>    echo $oilqty. "bottles of oil<br />";
>    echo $sparkqty. "spark plugs<br />";
> ?>
> </body>
> </html>
> ----------------------------------------

Derudover har jeg et andet råd: Brug meningsfulde navne, også
selv om de bliver lidt lange. Hvem kan om 3 måneder huske hvad
"tireqty" står for? Brug "tirequality" i stedet.

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

Bruno Christensen (13-03-2006)
Kommentar
Fra : Bruno Christensen


Dato : 13-03-06 19:10

On Mon, 13 Mar 2006 18:31:03 +0100, Bertel Lund Hansen wrote:

> Hvem kan om 3 måneder huske hvad
> "tireqty" står for? Brug "tirequality" i stedet.

De fleste kan nu godt huske at det er noget med antal

--
Med Venlig Hilsen
Bruno Christensen

Brian Danielsen (13-03-2006)
Kommentar
Fra : Brian Danielsen


Dato : 13-03-06 23:47

Bogen hedder: Sams - PHP and MySQL Web Development :) nu skal jeg
lige være sikker: er det mest korrekt at bruge $_POST['tireqty']
eller ej? :)

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

Mads Lie Jensen (14-03-2006)
Kommentar
Fra : Mads Lie Jensen


Dato : 14-03-06 07:29

On 13 Mar 2006 22:47:12 GMT, Brian Danielsen
<brian.v.danielsen@gmail.com> wrote:

>Bogen hedder: Sams - PHP and MySQL Web Development :) nu skal jeg
>lige være sikker: er det mest korrekt at bruge $_POST['tireqty']
>eller ej? :)

Det er mest korrekt at bruge den.
--
Mads Lie Jensen - mads@gartneriet.dk - ICQ #25478403

Gartneriet - nu ny indpakning (delvist i hvert fald): http://www.gartneriet.dk/

Geert Lund (14-03-2006)
Kommentar
Fra : Geert Lund


Dato : 14-03-06 20:04

Mads Lie Jensen wrote:

> Det er mest korrekt at bruge den.

Synes dog det er lidt vigtigt i den sammenhæng at nævne at det dermed
kræver at man husker at ved $_POST skal man altid sætte sin FORM op til
at bruge method="post" - da eksemplet igen vil fejle såfremt der
benyttes en standard GET (her bruges så $_GET).

Et alternativ kan være at bruge $_REQUEST der så refererer alle variable
der sendes via GET/POST/COOKIES.

--
Med venlig hilsen
Geert Lund,
www.GLD.dk

Bertel Lund Hansen (14-03-2006)
Kommentar
Fra : Bertel Lund Hansen


Dato : 14-03-06 20:54

Geert Lund skrev:

> Et alternativ kan være at bruge $_REQUEST der så refererer alle variable
> der sendes via GET/POST/COOKIES.

Men er det ikke bedst at benytte det præcise scope?

I ColdFusion går det hurtigere.

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

Geert Lund (14-03-2006)
Kommentar
Fra : Geert Lund


Dato : 14-03-06 22:37

Bertel Lund Hansen wrote:

>>Et alternativ kan være at bruge $_REQUEST der så refererer alle variable
>>der sendes via GET/POST/COOKIES.

> Men er det ikke bedst at benytte det præcise scope?

Joe, hvis man er klar over det præcise scope og husker at det kan ændre
sig når man springer mellem GET/POST forms af den ene eller anden årsag.

Men som både Mads og Jacob har været inde på - handler det jo egentlig i
sidste ende mest om at validere sine data uanset hvordan de kommer ind i
systemet - og så kan det IMHO være ligegyldigt hvilket scope af G/P/C de
kommer fra.

Er man ude i scripts der skal tricke specielt på "fakede" data - eller
at det er krævet at data fx kom ind via en cookie - så kan det være en
god ide at bruge det præcie scope til opgaven - ellers mener jeg ikke
det bør være nødvendigt - og vil ofte - specielt for nybegyndere - give
flere problemer end det vil løse for dem at skulle huske det kan ændre
sig. (Ja, for os andre der laver komplekse dataopsamlinger med
tilhørende forms vil det være et mindst lige så stort problem).

Men der er sikkert andre der vil anbefale netop at holde sig strict til
det specifikke scope - jeg ville bare være sikker på at $_REQUEST/$_GET
også er nvænt i forhold til kun at benytte $_POST


--
Med venlig hilsen
Geert Lund,
www.GLD.dk

Peter Brodersen (15-03-2006)
Kommentar
Fra : Peter Brodersen


Dato : 15-03-06 01:00

On Tue, 14 Mar 2006 20:53:53 +0100, Bertel Lund Hansen
<nospamfilius@lundhansen.dk> wrote:

>> Et alternativ kan være at bruge $_REQUEST der så refererer alle variable
>> der sendes via GET/POST/COOKIES.
>Men er det ikke bedst at benytte det præcise scope?

Det afhænger. Er der risiko for overlap (hvor fx en cookie- og en
get-variabel kan hedde det samme), er det selvfølgelig relevant.

Nogle vil nævne, at de bruger $_POST, idet det er sværere for evt.
pilfingre at ændre i variable og lave ulykker. Jeg har generelt høj
tiltro til pilfingre og antager, at de sagtens kan rette i en form
eller lave deres egne http-forespørgsler eller at de bruger diverse
værktøjer til også at manipulere med post-forespørgsler (fx
LiveHTTPHeaders eller Web Developer Toolbar til Firefox, og sikkert en
bunke andre tilsvarende værktøjer til øvrige browsere).

Til almindelige sider plejer jeg at være glad nok for at bruge
$_REQUEST, såfremt der sidder glade nørder derude, der hurtigt vil
automatisere et par opslag (og så er det mere tidsbesparende, at de
også kan lave get-requests).

>I ColdFusion går det hurtigere.

Jeg er ret sikker på at $_REQUEST allerede er evalueret / variable
allerede er lagt ind i $_REQUEST på forhånd, så der er næppe nogen
hastighedsforskel. Dog, jeg er ikke inde i den dybere magi, der nu og
da er involveret i phps superglobals.

--
- Peter Brodersen
Find dig selv: http://map.ter.dk/

Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408926
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste