[PHP] Vreemd probleem met $_GET

[Verwijderd]

Ok ik zit met een heel vreemd probleem waar meerdere mensen die werken met php voor hun beroep geen antwoord op kunnen geven. Hopelijk is hier iemand te vinden die ervaring heeft met dit probleem.

Het is eigenlijk heel simpel, als voorbeeld neem ik het id 5.

$boek = new Boek($_GET["id"]); // dit werkt niet en wordt niet opgeslagen in de database via het orm.
$boek = new Boek(5); // werkt en wordt wel opgeslagen in de database via het orm.
echo $_GET["id"]; // geeft 5.
echo $boek->id; // geeft 5 met $_GET["id"].

var_dump($_GET["id"]); zegt dat het een string 5 is. Ik heb het al proberen te casten naar een integer maar dat had geen effect. Maar blijkbaar zit er een verschil tussen gewoon een nummer en het nummer via de $_GET ($_POST geeft hetzelfde probleem). Maar wat? Ik snap het niet, op andere plekken van de applicatie doe ik precies hetzelfde maar daar werkt het wel gewoon..

[Voutloos]

Met de correcte cast naar int is het gedrag toch echt hetzelfde. Dus of je cast niet goed, of je doet ergens anders iets fout, maar aan PHP zelf zal het echt niet liggen.

Sowieso debugt het handiger dmv var_dump() / var_export() / echte debugger ipv echo. Misschien doet echo $boek->id al meer dan je denkt dankzij magic getters en/of __toString() of wat dan ook. Ook kan je met echo niet goed zien of je ook whitespace in je var hebt etc etc

[RainerSGF]

is de klasse (en constructor) van Boek goed gedefinieerd wat betreft die integer? Anders moet je misschien als alternatief eerst $_GET["id"] opslaan in een variabele vóóraf en dan deze gebruiken als

PHP:

new Boek(variabele)

[Mercatres]

Sowieso is het een bad practice om je $_GET-variabelen rechtstreeks naar een object door te geven.
Dus eerst sanitizen enzovoorts.

[ Voor 14% gewijzigd door Mercatres op 18-12-2011 14:23 ]

[Struikrover]

...maar daar zou je gewoon een wrapper functie voor kunnen aanroepen, die in combinatie met filter_input je variabele opschoont en weer teruggeeft. Iets als dit:

PHP:

function get_GET($getData, $type = null)
{
    if ( empty($getData) || !isset($_GET[$getData]) || ( isset($_GET[$getData]) && empty($_GET[$getData]) ) ){
        return false;
    }
    
    switch($type){
        case "name":
            return filter_input(INPUT_GET, $getData,  FILTER_SANITIZE_SPECIAL_CHARS, array(FILTER_FLAG_ENCODE_LOW));
        break;
        case "num":
            return filter_input(INPUT_GET, $getData, FILTER_SANITIZE_NUMBER_INT);
        break;
        case "email":
            return filter_input(INPUT_GET, $getData, FILTER_SANITIZE_EMAIL);
        break;
        default:
            return filter_input(INPUT_GET, $getData, FILTER_SANITIZE_SPECIAL_CHARS, array(FILTER_FLAG_ENCODE_LOW, FILTER_FLAG_ENCODE_HIGH));
        break;
    }
}

[T020]

in PHP maakt het niet heel veel uit of je een int in een string hebt staan, je kunt er dan nog steeds arithmetische operaties op uitvoeren meen ik:
"5" - 3 = 1
Dat kan verklaren waarom wat je wilt doen op andere plekken wel werkt.
Dat in $_GET["id"] een string staat is logisch, je browser geeft immers een querySTRING mee. Ik weet niet hoe je cast naar een integer, maar uit intval("5") zal toch echt een integer 5 komen. En zoals RainerSGF zegt: kijk even naar de constructor van de Boek klasse, wat deze met je variabele doet weten wij ook niet

[SvMp]

Aangezien TS dit schrijft:

PHP:

$boek = new Boek($_GET["id"]); // dit werkt niet en wordt niet opgeslagen in de database via het orm.
$boek = new Boek(5); // werkt en wordt wel opgeslagen in de database via het orm.
echo $_GET["id"]; // geeft 5.
echo $boek->id; // geeft 5 met $_GET["id"].

Trek ik de conclusie dat het object Boek deels wel werkt. Want als "echo $boek->id" de waarde 5 geeft met die GET, dan wordt het object gewoon gemaakt en krijgt de property 'id' de waarde 5. De constructor werkt in ieder geval deels. Ergens gaat er iets niet goed met wat er gebeurd in het object, maar wat kunnen we niet zeggen bij gebrek aan informatie.

[Verwijderd]

Het zit allemaal een beetje anders in elkaar dan gebruikelijk. Het werkt namelijk met een zelfgeschreven orm van het bedrijf, klassen worden gegenereerd en maken geen gebruik van een constructor. Het orm wordt al jaren gebruikt dus daar heb ik verder wel vertrouwen in. Het werkt ook gewoon met een getal alleen niet met een getal via een variable.

$id = $_GET["id"];
$id=intval($id); //var_dump geeft aan dat het ook inderdaad een int is geworden.
$boek = new Boek($id); // helaas hetzelfde probleem

@Mercatres, mee eens, maar het is voor intern gebruik, beveiliging heeft geen prioriteit en ik wil eerst het probleem oplossen voordat ik ga sanitizen.

Ik zal morgen als ik weer op me werk ben eens kijken of ik wat meer informatie kan geven.

[ Voor 0% gewijzigd door Verwijderd op 18-12-2011 15:09 . Reden: intval($id); naar $id=intval($id) ]

[Verwijderd]

Verwijderd schreef op zondag 18 december 2011 @ 14:52:
Het zit allemaal een beetje anders in elkaar dan gebruikelijk. Het werkt namelijk met een zelfgeschreven orm van het bedrijf, klassen worden gegenereerd en maken geen gebruik van een constructor. Het orm wordt al jaren gebruikt dus daar heb ik verder wel vertrouwen in. Het werkt ook gewoon met een getal alleen niet met een getal via een variable.

$id = $_GET["id"];
intval($id); //var_dump geeft aan dat het ook inderdaad een int is geworden.

Hier is $id nog steeds een string. De intval functie verandert geen argumenten, het is een functie met een return value waarmee je niets doet.
Waarom niet gewoon $id = intval($_GET["id"]) of $id = (int) $_GET["id"]?

[ Voor 7% gewijzigd door Verwijderd op 18-12-2011 14:56 ]

[SvMp]

@Schrauben: Klassen genereren en constructors sluiten elkaar niet uit. Uiteindelijk wordt er toch ergens een 'new' uitgevoerd, en daarbij wordt de constructor uitgevoerd indien aanwezig.

De code zoals je die schrijft werkt niet.
intval($id) verandert niets. Dat kan alleen met $id=intval($id) of $boek=new Boek(intval($id));

[Verwijderd]

Hm, sorry, ik bedoelde inderdaad $id=intval($id). (ben nog aan het ontnuchteren van gisteravond) Maar dat maakt dus helaas geen verschil. Ik zal morgen de klasse nog eens goed bekijken, misschien post ik die ook wel hier. Ik heb het project niet thuis.

[ Voor 46% gewijzigd door Verwijderd op 18-12-2011 15:04 ]

[Ventieldopje]

Ipv. dat we allemaal vanaf één kant gaan raden en het ORM er op vertrouwen dat het bug vrij is (hah, de grap!). Waarom ga je niet gewoon het ORM stap voor stap debuggen? Wordt de klasse aangemaakt, ontvangt hij de constructor parameter, is de constructor parameter het zelfde als de gene die ik er in stopte of hebben we te maken met magische code etc.

Als we alleen maar vanaf 1 kant gaan raden hoe het kan komen we nergens natuurlijk

[Morrar]

echo $boek->id; // geeft 5 met $_GET["id"].

Het feit dat dit werkt lijkt mij toch aan te geven dat er wel degelijk een object wordt aangemaakt toch? Dus ligt het probleem niet elders, bij de data-opslag bijvoorbeeld?

Als je:

$boek = new Boek(5);

Gebruikt en dat opslaat, werkt het dan wel? Zo niet, kijk dan eens naar het ORM. Misschien verwacht die nog wel meer properties van het boek object...

[ Voor 28% gewijzigd door Morrar op 18-12-2011 15:10 ]

[Verwijderd]

Dat zou goed kunnen alleen blijf ik het vreemd vinden dat $boek = new Boek(5); wel werkt. Debuggen hoopte ik te kunnen vermeiden want dat is nogal tijdrovend. Een object bevat namelijk ook alle relaties in dit geval, een var_dump geeft op een full hd scherm bijna een volledig scherm aan output waar je dan doorheen moet. Maar ik ben bang dat er weinig anders op zit.

[YopY]

Het lijkt me sowieso raar dat een entiteit (boek, in dit geval) al in de database opgeslagen wordt als je een model-object aanmaakt. Moet je niet nog ergens een save op aanroepen?

[Verwijderd]

YopY schreef op zondag 18 december 2011 @ 15:15:
Het lijkt me sowieso raar dat een entiteit (boek, in dit geval) al in de database opgeslagen wordt als je een model-object aanmaakt. Moet je niet nog ergens een save op aanroepen?

ja met $boek->commit();

[Ventieldopje]

Verwijderd schreef op zondag 18 december 2011 @ 15:15:
Dat zou goed kunnen alleen blijf ik het vreemd vinden dat $boek = new Boek(5); wel werkt. Debuggen hoopte ik te kunnen vermeiden want dat is nogal tijdrovend. Een object bevat namelijk ook alle relaties in dit geval, een var_dump geeft op een full hd scherm bijna een volledig scherm aan output waar je dan doorheen moet. Maar ik ben bang dat er weinig anders op zit.

Je hebt gelijk, oneindig blijven proberen en hulp zoeken op een forum met mensen die nog minder van het ORM weten dat jou is veel sneller!

Success met debuggen iig!

[Verwijderd]

Ventieldopje schreef op zondag 18 december 2011 @ 15:18:
[...]


Je hebt gelijk, oneindig blijven proberen en hulp zoeken op een forum met mensen die nog minder van het ORM weten dat jou is veel sneller!

Success met debuggen iig!

Aangezien $boek = new Boek(5); wel werkt ben ik er eigenlijk nog steeds van overtuigt dat het probleem niet in het ORM zit.

[YopY]

Verwijderd schreef op zondag 18 december 2011 @ 15:20:
[...]


Aangezien $boek = new Boek(5); wel werkt ben ik er eigenlijk nog steeds van overtuigt dat het probleem niet in het ORM zit.

Dan moet het wel in je eigen code zitten, niet? Heb je de debugger al eens opgestart?

[Matis]

Error reporting aanzetten en id eens een non-int waarde geven en kijken waar het script er uit klapt.