$_POST in een switch werkt soms

[Verwijderd]

Als bijbaantje, moet ik websites maken/verbeteren.Hier mee heb ik ook PHP geleerd, maar heb sinds een vorige week geleden een probleem die ik al op een Amerikaanse forum heb gepost echter wist niemand de oplossing. Hopelijk weten jullie het wel.


Het probleem:
Het probleem zit in case 'wijzig_prijs_metalstud' in de $_POST[id].

Het geval is dat in de die case het geen $_POST[id] weelt ontvangen. Die ik nodig heb om de product te updaten bij de juiste row.

Als ik het test met:

PHP:

$id = $_GET['id'];
if (isset($id)){

}

Werkt het wel in alle andere cases maar in de wijzig_prijs_metalstud niet.

Als ik handmatig de $_POST verander in een getal waarbij het product hoord, dan kan ik hem gewoon updaten. Dus ik ben er van overtuigt dat de $_POST niet werkt daarin.


case 'toon_prijs':

PHP: filename

case 'toon_prijs':
        
        
        $rsPlafondPlaatPrijs=("SELECT * FROM metalstud_prijzen WHERE id='$_GET[id]'");
        $queryPrijsPlafondplaat=mysql_query($rsPlafondPlaatPrijs) or die(mysql_error());

        if($result_prijs=mysql_fetch_array($queryPrijsPlafondplaat)) {
            $id="<input type='hidden' name='id' value='$result_prijs[id]' />";
            
            $type=$result_prijs['type'];
            $lengte=$result_prijs['lengte'];
            $breedte=$result_prijs['breedte'];
            
            $prijs=$result_prijs['prijs'];
            $prijs_notatie=$result_prijs['prijs_notatie'];
            
            ## afbeelding weergeven ##
            
            if($result_prijs['afbeelding']!="geenafbeelding.jpg") {
                $file_field="<img  src='../producten/".$result_prijs['afbeelding']."' border='1'  width='100'><br><a  href='index.php?pagina=metalstud_prijzen&product=$_GET[product]&id_product=$_GET[id_product]&id=$_GET[id]&aktie=wis_afbeelding'  class='link'>wis afbeelding</a><input type='hidden'  name='afbeelding' value='$result_prijs[afbeelding]' />";
                                                                                                                          //index.php?pagina=metalstud_prijzen&product=plafondplaten&id_product=1&id=3&aktie=toon_prijs
            } else {
                $file_field="<input type='file' name='afbeelding' id='afbeelding' />";
            }

        }
        $button="<input type='submit' name='button' id='button' value='wijzig prijs' />"; $aktie="wijzig_prijs_metalstud";
        
        break;

case 'wijzig_prijs_metalstud':

PHP:

    ## prijs plafond plaat wijzigen ##
        
        case 'wijzig_prijs_metalstud':
        
        $ruPlafondPlaatPrijs=("UPDATE metalstud_prijzen SET  afbeelding='$afbeelding', type='$_POST[r_type]',  lengte='$_POST[r_lengte]', breedte='$_POST[r_breedte]',  prijs='$_POST[r_prijs]', prijs_notatie='$_POST[r_prijs_notatie]' WHERE  id='$_POST[id]' ");
        mysql_query($ruPlafondPlaatPrijs) or die (mysql_error());
            
        $button="<input type='submit' name='button' id='button'  value='voeg prijs toe' />"; $aktie="prijs_metalstud_toevoegen";  $file_field="<input type='file' name='afbeelding' id='afbeelding'  />";
        
        $melding="<p class='melding'>De prijs is gewijzigd.</p>";

        break;
        
        default: $button="<input type='submit' name='button'  id='button' value='voeg prijs toe' />";  $aktie="prijs_metalstud_toevoegen"; $file_field="<input type='file'  name='afbeelding' id='afbeelding' />";

Bouw van de table 'metalstud_prijzen':
Array ( [Field] => id [Type] => int(11) [Null] => [Key] => PRI [Default] => [Extra] => auto_increment ) Array ( [Field] => id_product [Type] => int(11) [Null] => [Key] => [Default] => 0 [Extra] => ) Array ( [Field] => afbeelding [Type] => varchar(255) [Null] => [Key] => [Default] => [Extra] => ) Array ( [Field] => type [Type] => varchar(255) [Null] => [Key] => [Default] => [Extra] => ) Array ( [Field] => lengte [Type] => varchar(255) [Null] => [Key] => [Default] => 0 [Extra] => ) Array ( [Field] => breedte [Type] => varchar(255) [Null] => [Key] => [Default] => 0 [Extra] => ) Array ( [Field] => prijs [Type] => float [Null] => [Key] => [Default] => 0 [Extra] => ) Array ( [Field] => prijs_notatie [Type] => varchar(255) [Null] => [Key] => [Default] => [Extra] => ) Array ( [Field] => online [Type] => enum('0','1') [Null] => [Key] => [Default] => 0 [Extra] => )

[HenkEisDS]

Als wijzig_prijs_metalstud dmv van POST wordt verstuurd, dan zal hij bij een GET inderdaad niet kunnen aangeven dat hij geset is.

[Niemand_Anders]

Op het moment dat jij het ID wilt ophalen bij een wijziging komt het ID via een HTTP POST, dus kun je op dat moment niet het ID uitlezen via $_GET. Een snelle simpele fix is om het id op te nemen in de post url.

Een structurele oplossing is om bijvoorbeeld eerst te proberen een id uit de $_POST collectie te lezen en daarna in de $_GET collectie te kijken.

[CodeCaster]

Zal ik de mogelijkheid tot SQL injection nog inkoppen, ook al gaat het waarschijnlijk om een beheerpagina die achter een login zit? En zal ik dan maar niet beginnen over het databaseontwerp, waarbij een tabel per product wellicht niet de meest handigeoplossing is?

[ Voor 33% gewijzigd door CodeCaster op 19-04-2011 16:48 ]

[Verwijderd]

CodeCaster schreef op dinsdag 19 april 2011 @ 16:47:
Zal ik de mogelijkheid tot SQL injection nog inkoppen, ook al gaat het waarschijnlijk om een beheerpagina die achter een login zit? En zal ik dan maar niet beginnen over het databaseontwerp, waarbij een tabel per product wellicht niet de meest handigeoplossing is?

Ik heb hem ook niet gemaakt hoor, hij deed het opeens niet zeiden ze tegen mij.

#Niemand_Anders


Kan je me daar een voorbeeld van geven, en is dat het zelfde als een cURL?

[Manuel]

Verwijderd schreef op dinsdag 19 april 2011 @ 17:07:
[...]


Ik heb hem ook niet gemaakt hoor, hij deed het opeens niet zeiden ze tegen mij.

Dus als ik het goed begrijp zoek je een quick-fix?

Maar goed. Lees voor antwoorden eens Programming FAQ - Algemeen door.

[ Voor 2% gewijzigd door Manuel op 19-04-2011 17:16 . Reden: * typo ]

[Cartman!]

Kortom: je haalt POST en GET door elkaar en je script is zo lek als een mandje

[ReenL]

PHP:

$id = $_GET['id'];
if (isset($id)){

}

PHP:

if (!isset($_GET['id'])){
    // TODO 404 error;
    exit;
}
$id = $_GET['id'];

Jou methode geeft foutmeldingen (error_reporting(E_ALL)). Of je dit nu met POST of met GET doet.

[ Voor 7% gewijzigd door ReenL op 19-04-2011 21:01 ]

[Precision]

Maak er dan zoiets van, waarbij de array_map je scheve applicatie (sql injectie) enigzins rechttrekt, alles aanpassen zal je lang duren en je loopt het risico om 1 te vergeten:

PHP:

<?php
$user_input = array();
if(!empty($_POST)) {
    $user_input = $_POST;
} elseif(!empty($_GET)){
    $user_input = $_GET;
} else {
    //exception
}
$user_input = array_map("map_entities", $user_input);

function map_entities($input){
    if(get_magic_quotes_gpc()) {
        return $input;
    }
    if(is_array($input)) {
        return array_map ("map_entities", $input);
    }
    if (function_exists('addslashes')){
        return addslashes($input);
    } elseif(function_exists('mysql_real_escape_string')) {
        return mysql_real_escape_string($input);
    } else {
        //exception
    }
}
?>

[Verwijderd]

Als je toch beide wilt gebruiken; alle variabelen staan in $_REQUEST, zowel de $_GET als de $_POST. Je zou moeten opzoeken welke prioriteit krijgt, anders kunnen mensen $_POST variabelen overschrijven door een $_GET mee te geven.

Beter is gewoon beslissen welke je wilt gebruiken, en die altijd gebruiken. $_GET is voor het opvragen van informatie (bijvoorbeeld een ID van een pagina die je wilt opvragen 'hoort' eigenlijk in de $_GET) en $_POST is voor het versturen van gegevens, dus een gewijzigde pagina of nieuwe comment moet eigenlijk gePOST worden. (Je hebt ook nog PUT en DELETE voor het respectievelijk updaten en verwijderen van content, maar die worden minder gebruikt dan GET en POST, ik weet ook niet of PHP ze standaard oppikt.)

Wikipedia: Hypertext Transfer Protocol

[ Voor 20% gewijzigd door Verwijderd op 20-04-2011 18:57 ]

[Manuel]

@Precision:

Ja, het is zeker verstandig om gebruik te maken van addslashes en magic quotes! Waarom zou anders de mysql_real_escape functie zijn gemaakt als addslashes het kan vervangen. Het beste zou zijn gebruik maken van parameterized queries en dat je zelf bepaald wat je wel of niet escaped, aangezien niet alles hoeft te worden geëscaped (zoals een wachtwoord bijvoorbeeld).

Ik kan mij vaag herinneren dat hier ook al eerder een discussie over is geweest maar kan zo de betreffende post niet vinden met argumenten.

Voor magic quotes, zie de php.net website alleen al:

Warning
This feature has been DEPRECATED as of PHP 5.3.0. Relying on this feature is highly discouraged.

Kort gezegd: Niet het bovenstaande 'hulpmiddel' gebruiken.

[ Voor 3% gewijzigd door Manuel op 20-04-2011 18:57 ]

[Precision]

Ik zeg ook niet dat je het zo moet doen, maar als zijn queries die hij aanrijkt lek zijn en hij heeft het niet zelf gemaakt, dan kun je beter een lapmiddel gebruiken dan ze lek laten. We weten niet hoe groot de applicatie is, als hij met 1000 queries zit dan wens ik hem veel succes om uit te leggen waarom hij die 20u extra werk heeft gehad, het zal zijn opdrachtgever weinig kunnen schelen en ze zullen gewoon denken dat hij extra uren wil kloppen, het werkte voordien toch ook gewoon? Ideaal is natuurlijk om parameterized queries te gebruiken, maar helaas leven we niet in een ideale wereld.

Manuel schreef op woensdag 20 april 2011 @ 18:56:
@Precision:

Ja, het is zeker verstandig om gebruik te maken van addslashes en magic quotes! Waarom zou anders de mysql_real_escape functie zijn gemaakt als addslashes het kan vervangen. Het beste zou zijn gebruik maken van parameterized queries en dat je zelf bepaald wat je wel of niet escaped, aangezien niet alles hoeft te worden geëscaped (zoals een wachtwoord bijvoorbeeld).

Ik kan mij vaag herinneren dat hier ook al eerder een discussie over is geweest maar kan zo de betreffende post niet vinden met argumenten.

Voor magic quotes, zie de php.net website alleen al:

Warning
This feature has been DEPRECATED as of PHP 5.3.0. Relying on this feature is highly discouraged.

Kort gezegd: Niet het bovenstaande 'hulpmiddel' gebruiken.

PHP:

<?php
$_POST = array_map("map_entities", $_POST);
$_GET = array_map("map_entities", $_GET);

function map_entities($input){
    if(get_magic_quotes_gpc()) {
        return $input;
    }
    if(is_array($input)) {
        return array_map ("map_entities", $input);
    }
    if (function_exists('addslashes')){
        return addslashes($input);
    } elseif(function_exists('mysql_real_escape_string')) {
        return mysql_real_escape_string($input);
    } else {
        //exception
    }
}
?>

[ Voor 35% gewijzigd door Precision op 20-04-2011 21:48 ]

[CodeCaster]

Nee!

Het gedrag is er niet voor niks uitgesloopt. Je wil helemaal geen slashes toevoegen aan alle POST- en GET-velden. Pas als ze de database in gaan, en daarvoor gebruik je weer parametrized queries met een escape-functie.

[Manuel]

Precision schreef op woensdag 20 april 2011 @ 19:17:
Ik zeg ook niet dat je het zo moet doen, maar als zijn queries die hij aanrijkt lek zijn en hij heeft het niet zelf gemaakt, dan kun je beter een lapmiddel gebruiken dan ze lek laten. We weten niet hoe groot de applicatie is, als hij met 1000 queries zit dan wens ik hem veel succes om uit te leggen waarom hij die 20u extra werk heeft gehad, het zal zijn opdrachtgever weinig kunnen schelen en ze zullen gewoon denken dat hij extra uren wil kloppen, het werkte voordien toch ook gewoon? Ideaal is natuurlijk om parameterized queries te gebruiken, maar helaas leven we niet in een ideale wereld.

En wie kijken ze aan als de applicatie wel een keer goed gekraakt wordt? Ik neem aan dat ze dan eerst naar de developer kijken die het geschreven / aangepast heeft. Daarna komen ze verhaal halen waarom dat wel niet gebeurd zou kunnen zijn.

Ik zit er liever 20 uur extra bij dan dat ik er binnenkort bij mag klooien het te lopen herstellen en alsnog het probleem oplossen als gevolg dat iemand 'mijn' leuke website heeft gekraakt. Je bezorgt jezelf namelijk alleen maar extra werk. Escape alleen als het echt nodig is, anders laten zitten.

Wellicht creeër je met deze 'extra beveiligingsmaatregel' alleen maar meer werk voor jezelf omdat er ineens zaken worden geëscaped die eigenlijk niet geëscaped hadden hoeven worden. Bijna alles wat naar je database gaat moet worden geëscaped om SQL-injecties te voorkomen.

[Enfer]

De enige correcte oplossing als je zoiets tegenkomt (laatst zelf nog in levende lijve ondervinden) is dit aan de klant voorleggen en hem/haar vragen wat er mee moet gebeuren.. Neemt de klant het risico, dan laat je de klant tekenen dat jij niet aansprakelijk bent voor de eventuele gevolgen.. Wil de klant het laten herschrijven heb jij je weer wat werk op de hals gehaald..

[alwinuzz]

Volgens mij heeft Enfer gelijk, vragen wat de klant wil.

Verder, CodeCaster wat is mis met de volgende code uit te voeren aan het begin van elk request? User input schoonmaken, dit icm magic quotes uitgezet.

PHP:

<?php 
    $_POST = array_map("map_entities", $_POST); 
    $_GET = array_map("map_entities", $_GET); 

function map_entities($input){ 
    if(is_array($input)) { 
        return array_map ("map_entities", $input); 
    } else { 
        return mysql_real_escape_string($input); 
    } 
} 
?>

PS: input meerdere malen escapen (magic quotes + addslashes + meerdere malen mysql_real_escape_string) is echt een nachtmerrie...

@altrincham: ik doelde niet op de code van Precision. Gelukkig weet ik wat return doet, maar met PHP weet je het nooit natuurlijk

Bedoelde meer dit: ik heb wel eens een site gezien waar de maker gehoord had dat mysql_real_escape_string goed was, en dat dus lukraak gebruikte om meerdere keren dezelfde input/output te escapen. Magic quotes stonden nog aan.
Vervolgens snapte hij niet waarom elke keer overal meerdere slashes tussen kwamen. Maarja als je de slashes escapet, en die weer escapet, en die wéér...

[ Voor 28% gewijzigd door alwinuzz op 20-04-2011 23:18 ]

[Precision]

Het is fout als je het bijvoorbeeld nog wil tonen op het scherm en zo zijn er nog wel genoeg scenario's (if...) te verzinnen, dan zal die \" er ook bijstaan, je kunt dan eventueel die slashes terug gaan strippen, maar dan is het niet meer zo performant.

alwinuzz schreef op woensdag 20 april 2011 @ 21:38:
Volgens mij heeft Enfer gelijk, vragen wat de klant wil.

Verder, CodeCaster wat is mis met de volgende code uit te voeren aan het begin van elk request? User input schoonmaken, dit icm magic quotes uitgezet.

PHP:

<?php 
    $_POST = array_map("map_entities", $_POST); 
    $_GET = array_map("map_entities", $_GET); 

function map_entities($input){ 
    if(is_array($input)) { 
        return array_map ("map_entities", $input); 
    } else { 
        return mysql_real_escape_string($input); 
    } 
} 
?>

PS: input meerdere malen escapen (magic quotes + addslashes + meerdere malen mysql_real_escape_string) is echt een nachtmerrie...

Als get_magic_quotes_gpc aanstaat dan heb je de input er net 2x doorgedraaid, in mijn voorbeeld keek hij of het aanstond en deed verder niets, de 2e parameter (optioneel) bij mysql_real_escape_string is de resource, bij sommige servers is dit verplicht, daarom keek ik eerst of addslashes aanstond.

[ReenL]

Als we toch zinloze code aan het posten zijn gebruik dan:

PHP:

<?php
$_GET = $_POST = $_SESSION = $_REQUEST = $_COOKIE = $_SERVER = array();
?>

Zo, probeer nu maar eens te sql injecten!
[/sarcasm]

Tip1: Leer wat SQL-Injection is;
Tip2: Pas daar preventie voor toe;
Tip3: Zorg dat het veilig is op het moment dat magic quotes uit staat.

[Verwijderd]

alwinuzz schreef op woensdag 20 april 2011 @ 21:38:
PS: input meerdere malen escapen (magic quotes + addslashes + meerdere malen mysql_real_escape_string) is echt een nachtmerrie...

Volgens mij moet jij nog ff leren wat return doet

Voor de rest, het is idd erg lek

@TS: http://www.tizag.com/phpT/postget.php
Lees dat eens door. Dan snap je wel wat er fout ging

[Verwijderd]

Héél erg bedankt voor de reacties.
Maar heb nog geen oplossing, heb ondertussen wat dingen geprobeerd, maar niks helpt.

#Precision
Moet ik die code van jou nou bovenaan plaatsen?
Zoja, dat werkte niet.


Meer info:

De website deed het eerst wel goed en nu niet meer.


Alles behalve de invul gegevens en tabel naam is dat andere producten paginas bijna de zelfde code hebben en gewoon goed functioneren.

[Verwijderd]

Om het gemakkelijker te maken:


De Kapotte:

*knip*

[ Voor 101% gewijzigd door MueR op 21-04-2011 10:28 ]

[MueR]

Goed, toen was het over. Dit topic heeft lang genoeg doorgehobbeld. Het begon als een mooie kans om iemand wat hedendaagse PHP kennis bij te brengen, maar het is ondertussen een partijtje handje vasthouden om tot een oplossing te komen. Zo werken we hier niet. Ik stel voor dat je eerst leert programmeren voordat je er betaalde klussen voor aanneemt.

Badr., wil je voordat je nieuwe topics open de Quickstart en Help, mijn script werkt niet (goed) eens doorlezen?

[ Voor 9% gewijzigd door MueR op 21-04-2011 10:31 ]