[PHP] PHP 4 en ?var=wat

[amphora]

Ik heb zojuist PHP4 op een IIS 4.0 op NT Server 4.0 geinstalleerd. Het lijkt te werken, maar.....

Ik heb een script: index.php
Ik geef als url in browser: index.php?id=1
in het script doe ik een: echo $id;
waarom is die variabele leeg? Met PHP3 ging 't prima.
Hij parsed het script ook verder goed. Want alle andere PHP code voert ie gewoon uit. Hij leest alleen die variabelen niet goed.

[Verwijderd]

Heb je toevallig de optimized php.ini gebruikt? Want die heeft een aantal dingetjes uitstaan ivm performance...

[amphora]

Inderdaad.
Nou lekker optimized dan

Bedankt

[Sabbath]

Maar hoe heb je dit nou opgelost dan??? want ik heb namelijk het zelfde probleem...

edit:
Ik heb het al:
register_globals = On
Die stond op Off...
_{(Mischien handig voor andere mensen die tegen het zelfde probleem op lopen, kunnen ze de search gebruiken )}

[Nielsz]

$http_post_vars;
$http_get_vars;
$_post;
$_get;

[Dennis]

Op donderdag 25 april 2002 13:55 schreef Nielsz het volgende:
$http_post_vars;
$http_get_vars;
$_post;
$_get;

FOUT!!!!!!!!!!

HOOFDLETTERS!
$_POST
$_GET

[einde mededeling]

[Janoz]

Luister naar nielsz ipv naar Sabbath. Het is namelijk niet voor niks dat de standaard instalatie deze optie uit heeft staan. Daarnaast werkt het gebruik van de door Nielsz genoemde arrays ALTIJD (of globals nu aan of uit staat) en weet je altijd waar je vars vandaan komen..

D'r missen trouwens nog wel een paar

$HTTP_SESSION_VARS (of $_SESSION)
$HTTP_COOKIE_VARS (of $_COOKIE)

[Nielsz]

Op donderdag 25 april 2002 14:23 schreef ddc het volgende:

[..]

FOUT!!!!!!!!!!

HOOFDLETTERS!
$_POST
$_GET

[einde mededeling]

stfu

Verder hebben we nog:
$GLOBALS
$_SERVER
$_FILES
$_ENV
$_REQUEST

[drm]

als je 't prettig vind kun je de extract functie gebruiken, die de variabelen alsnog globalised. Kan handig zijn.

Hoe dan ook geldt dat je heel erg kien moet zijn op het controleren van je input.

_{edit: typo}

[Bosmonster]

Het idee achter een default register_globals=Off is niet zozeer performance, maar meer security, om logische redenen.

Maar zelfs al ondersteunt jouw server wel register_globals dan nog zou ik de "safe" manier gebruiken. Je weet maar nooit of je het uiteindelijk op een echte webserver wilt gaan zetten en dan kan ik je garanderen dat ze register_globals uit hebben staan

Scheelt je dan een hoop herbouwen.

[Dennis]

Op donderdag 25 april 2002 14:48 schreef Nielsz het volgende:
Verder hebben we nog:
$GLOBALS

[Nielsz]

Op donderdag 25 april 2002 15:14 schreef ddc het volgende:

[..]

He ik loop ook maar de predefined.variabeles langs op php.net

[Dennis]

Nielsz:
He ik loop ook maar de predefined.variabeles langs op php.net

Ik vergeef je

[rvrbtcpt]

Zet dit gewoon aan het begin van je script:

code:

if( isset($HTTP_POST_VARS['id']) ) {
    $id = $HTTP_POST_VARS['id'];
} else {
    if( isset($HTTP_GET_VARS['id']) ) {
        $id= $HTTP_GET_VARS['id'];
    } else {
        $id= "";
    }
}

Als de variabele ID dan in een form post zit of in je URL dan heb je em.

[Martin Sturm]

$HTTP_*_VARS wordt sinds 4.1.0 afgeraden te gebruiken. Deze zijn namelijk allemaal vervangen door $_GET, $_POST, $_SESSION enz. die worden wel aangeraden te gebruiken. $HTTP_*_VARS gaan wellicht ooit niet meer gebruikt worden (aldus de php site )

[Sabbath]

Op donderdag 25 april 2002 14:23 schreef Janoz het volgende:
Luister naar nielsz ipv naar Sabbath. Het is namelijk niet voor niks dat de standaard instalatie deze optie uit heeft staan. Daarnaast werkt het gebruik van de door Nielsz genoemde arrays ALTIJD (of globals nu aan of uit staat) en weet je altijd waar je vars vandaan komen..

D'r missen trouwens nog wel een paar

$HTTP_SESSION_VARS (of $_SESSION)
$HTTP_COOKIE_VARS (of $_COOKIE)

[wijsneusmodes]
En wat is dan de reden dat ie uit staat??
[/wijsneusmodes]

[Nielsz]

Op vrijdag 26 april 2002 13:47 schreef Sabbath het volgende:

[..]

[wijsneusmodes]
En wat is dan de reden dat ie uit staat??
[/wijsneusmodes]

Omdat je anders via de url variabelen kan wijzigen die helemaal niet gewijzigd mogen worden.

[Sabbath]

Op vrijdag 26 april 2002 13:50 schreef Nielsz het volgende:

[..]

Omdat je anders via de url variabelen kan wijzigen die helemaal niet gewijzigd mogen worden.

zit wat in....... oke, dan gaan we het anders doen thx voor de tip

[rvrbtcpt]

Op vrijdag 26 april 2002 10:19 schreef Martin Sturm het volgende:
$HTTP_*_VARS wordt sinds 4.1.0 afgeraden te gebruiken. Deze zijn namelijk allemaal vervangen door $_GET, $_POST, $_SESSION enz. die worden wel aangeraden te gebruiken. $HTTP_*_VARS gaan wellicht ooit niet meer gebruikt worden (aldus de php site )

Dat klopt maar het is niet duidelijk welke 4.x versie hij gebruikt.
Daarbij komt nog dat ik niet te spreken ben over het gebruik van sessie variabelen in de 4.2 versie. Dat werkt niet altijd. Dus misschien dat ze hier met die nieuwe variabelen ook nog bugs hebben. Tot nu toe werkt deze methode ook nog in zowel de oude als de nieuwe versies.

[Janoz]

Het ombouwen van een script dat gebruik maakt van de HTTP_*_VARS naar een script dat gebruik maakt van _* is een stuk simpeler dan het ombouwen van een script dat er nog helemaal geen gebruik van maakt. In het eerste geval kun je gewoon gebruik maken van de vele replace functies die bijna elke editor wel heeft zonder echt bang te hoeven zijn dat de functionaliteit van je script onderuit gehaald wordt.

[Verwijderd]

Je kan dit ook gebruiken als je provider niet de php.ini wil veranderen.
Dan maakt hij netjes weer $var met de waarde 'wat'

code:

foreach ($_GET as $veld => $gegevens) {
$_GET["$veld"] = Addslashes($gegevens);
$$veld = Addslashes($gegevens);
}
foreach ($_POST as $veld => $gegevens) {
$_POST["$veld"] = Addslashes($gegevens);
$$veld = Addslashes($gegevens);
}
foreach ($_COOKIE as $veld => $gegevens) {
$_COOKIE["$veld"] = Addslashes($gegevens);
$$veld = Addslashes($gegevens);
}
foreach ($_SESSION as $veld => $gegevens) {
$_SESSION["$veld"] = Addslashes($gegevens);
$$veld = Addslashes($gegevens);
}

Ik hoop dat het goed werkt,
Heb hem nog niet echt goed getest

Op donderdag 25 april 2002 16:18 schreef Frijns.Net het volgende:
Zet dit gewoon aan het begin van je script:

code:

if( isset($HTTP_POST_VARS['id']) ) {
    $id = $HTTP_POST_VARS['id'];
} else {
    if( isset($HTTP_GET_VARS['id']) ) {
        $id= $HTTP_GET_VARS['id'];
    } else {
        $id= "";
    }
}

Als de variabele ID dan in een form post zit of in je URL dan heb je em.

[Verwijderd]

Op vrijdag 26 april 2002 13:50 schreef Nielsz het volgende:

[..]

Omdat je anders via de url variabelen kan wijzigen die helemaal niet gewijzigd mogen worden.

Welken zo al ?
Om bv DOCUMENT_ROOT niet die blijft gewoon het zelfde.

[Janoz]

Op woensdag 01 mei 2002 16:49 schreef StephanPHP het volgende:

[..]

Welken zo al ?
Om bv DOCUMENT_ROOT niet die blijft gewoon het zelfde.

In de meeste scripts worden wel meer variabelen gebruikt dan DOCUMENT_ROOT.. Vooral sessie variabelen die aangeven wat de userstatus of de inlogstatus is zijn gewilde slachtoffers. Daarnaast zijn er ook allemaal leuke dingen te doen met GET variabelen die je bijvoorbeeld mbv een plaatje laat uitvoeren. Waneer je niet gebruik maakt van de eerder genoemde arrays kun je eigenlijk nooit achterhalen of iets uit een sessie, post, cookie of get komt. Er zijn legio voorbeelden om hier misbruik van te maken.

[Verwijderd]

Op woensdag 01 mei 2002 16:55 schreef Janoz het volgende:

[..]

In de meeste scripts worden wel meer variabelen gebruikt dan DOCUMENT_ROOT.. Vooral sessie variabelen die aangeven wat de userstatus of de inlogstatus is zijn gewilde slachtoffers. Daarnaast zijn er ook allemaal leuke dingen te doen met GET variabelen die je bijvoorbeeld mbv een plaatje laat uitvoeren. Waneer je niet gebruik maakt van de eerder genoemde arrays kun je eigenlijk nooit achterhalen of iets uit een sessie, post, cookie of get komt. Er zijn legio voorbeelden om hier misbruik van te maken.

Opzich gebruik ik al zins PHP 4.06 al geen $var meer maar de $HTTP_*_VARS versie en zins PHP 4.1.0 de $_* versie.
Maar was gewoon nieuwschierig

[Verwijderd]

Sorry voor het schoppen, maar ik heb dus ook 4.20 als ik registerglobals op on zet doet die het dus niet ( met die variabelen ) en als die variabelen in me php script zet pakt die ze ook niet!

Iemand een verfijnde uitleg wat ik moet doen ? wil het liefst het in de php.ini veranderd hebben.

[Verwijderd]

oke gevonden via een andere site de aanroep in je script moet dan het volgende zijn, is handig voor andere mensen die weer op UTFS worden gericht.

als je dit hebt http://ip/index.php?naam=blaaht

gebruik je het volgende ...


echo $_GET['naam'] . '<br />';

[TheRebell]

Op zaterdag 04 mei 2002 15:21 schreef Sanders het volgende:
oke gevonden via een andere site de aanroep in je script moet dan het volgende zijn, is handig voor andere mensen die weer op UTFS worden gericht.

als je dit hebt http://ip/index.php?naam=blaaht

gebruik je het volgende ...


echo $_GET['naam'] . '<br />';

Dus als ik het goed heb kun je nu via je url (of adresbalk-dinges) geen variabelen meer meesturen. Mits je "register_globals =" op OFF hebt staan???
Zou mooi zijn, want dan hoef ik niet moeilijk te doen om ervoor te zoren dat je niet zomaar kan klooien met je url (andere namen enzo invullen )

[TheRebell]

Uhhhh..... ik vat hem geloof ik niet helemaal....

Als ik "register_globals" op OFF zet en vervolgend $HTTP_POST_VARS[naamVariabele] gebruik dat werkt dit dus alleen met data dat via een form wordt doorgegeven.
Maar hoe kan ik nu dit laten werken via een url

Als ik dus nu een plaatje heb als link

code:

<a href=pagina.php?naam=therebell>plaatje:)</a>

dan werkt dit dus niet
Hoe kan ik dan wel via een link data doorgeven maar dan wel zo dat je er niet mee kiunt klooien??

Of moet ik dan mijn data registreren in een sessie en daarna aanroepen op een pagina

[Glimi]

$_GET? HTTP_GET_VARS[] ?

Enig id wat POST in HTTP_POST_VARS betekend?

[TheRebell]

Op maandag 06 mei 2002 22:25 schreef Glimi het volgende:
$_GET? HTTP_GET_VARS[] ?

Enig id wat POST in HTTP_POST_VARS betekend?

Als jij in je form de methode post gebruikt
Dus met get zou het moeten werken als ik het goed begrijp?

[Glimi]

2 punten voor jou.
Kijk anders nog even het HTTP protocol een beetje door, dan wordt je een hoop duidelijk

[TheRebell]

Op maandag 06 mei 2002 22:46 schreef Glimi het volgende:
2 punten voor jou.
Kijk anders nog even het HTTP protocol een beetje door, dan wordt je een hoop duidelijk

Thnx