Kan resultaat niet zien van query

  • Hallo,


    ik ben bezig aan een projectje voor mezelf en ben net begonnen aan de code voor de login. Om één of andere reden kan ik het resultaat van mijn query niet zien maar ik zou niet weten waarom. Doe ik hier iets verkeerd? Ik doe het normaal gezien altijd zo en ik zou dus niet weten waarom het nu niet werkt.
    Ik zit hier ondertussen toch al even te prutsen dus leek het me makkelijker om het hier even te vragen. In $row komt er geen resultaat te staan maar ik zou niet weten hoe dit komt.
    Het zal waarschijnlijk iets stoms zijn, maar ik ben dan ook nog een amateur :rolleyes:
    Andere commentaren op mijn code zijn ook altijd welkom zodat ik kan bijleren :)
    Dit is mijn code:

  • Je query heeft waarschijnlijk geen resultaten. Die { accoladen } zijn een PHP-ding, in die zin dat ik die vaak in PHP-code zie, terwijl die eigenlijk daar ook al weinig/niets toevoegen.


    Ze horen niet thuis in SQL, tenzij je een e-mailadres echt hebt opgeslagen als {[email protected]}, wat ik betwijfel.


    Oftewel: accolades weghalen. Dan heb je waarschijnlijk wel / meer resultaat.


    EDIT: enne, na een header('Location: ...'); hoort bijna altijd een exit te staan zoals ik al vaker heb toegelicht.

  • Probeer het zo eens

  • Bedankt! De accolades hebben inderdaad het probleem opgelost, ik had ergens gelezen dat ze helpen tegen sql injection doordat ze laten zien wat het begin en einde is van een value maar blijkbaar is dat dan toch iets dat ik beter niet toepas of niet klopte.
    Verder ook bedankt voor de tips en de verbeteringen in mijn code! :)
    Ik zie dat jij bijvoorbeeld $conn->escape_string gebruikt inplaats van mijn mysqli_real_escape_string dat ik gebruik, en ook $result->num_rows waar ik dan mysqli_num_rows($result) zou gebruiken. Is dit een betere manier van programmeren of is het gewoon persoonlijke voorkeur?

  • @FangorN
    Lieve beeldschermkinderen,
    Hierbij de code met comment lines erbij


  • @matistop333
    Ik hou liefst bij 1 manier van schrijven ipv dingen door elkaar te gooien. Zo houd je het overzichtelijk voor jezelf. Maar zie hierboven de extra comments.


    Zelf gebruik ik nog een class om input te filteren aan bepaalde waarden.
    dus zou ik ook nog filter_var($_POST['email'],FILTER_VALIDATE_EMAIL) toevoegen om te kijken of er een email adres is ingevuld en voor wachtwoord bijvoorbeeld:
    preg_match("/^[a-zA-Z0-9-_!?+]*$/",$_POST['wachtwoord']);
    Hierbij mag wachtwoord alleen maar de letters, cijfers en een paar tekens bevatten.

  • ik had ergens gelezen dat ze helpen tegen sql injection doordat ze laten zien wat het begin en einde is van een value maar blijkbaar is dat dan toch iets dat ik beter niet toepas of niet klopte.

    Accolades voorkomen SQL injection niet. Deze maken het hooguit (iets) lastiger om dit te doen maar uiteindelijk biedt dit onvoldoende bescherming.


    Het enige wat failsafe is is het gebruik van (single) quotes (om de te escapen waarde) in combinatie met een escape-functie (voor het escapen van de waarde zelf). Het een zonder het ander is niet veilig.


    Ook is het een goede gewoonte om je invoer te filteren. Als je bijvoorbeeld een numerieke waarde verwacht: controleer hier dan ook op.


    Wat @MOnkNL doet is consequent de object georiënteerde schrijfwijze toepassen. Dit is niet per definitie beter, maar anders. En zeker wat korter. En waarschijnlijk meer in lijn met hoe MySQLi werkt (met klassen en objecten). In het algemeen beweegt programmeren (in PHP) weg van procedureel en naar object georiënteerd toe. Je kunt je eigen voorkeur hebben, maar wat handig/verstandig is lijkt mij duidelijk.


    Wat naar mijn mening niet/minder handig is is het volgende: hetgeen je gebruikt zijn nog steeds specifieke MySQL(i)-functies en -methoden. Hierbij bedien je je min of meer van "hardcoding van de database-oplossing". De SQL-code is ook nog steeds "MySQL specifiek", daar kom je ook niet omheen tenzij je een Database Abstraction Layer hebt, maar dat terzijde.


    Sommigen van jullie zijn nu bezig met een omzetting van functies van de oorspronkelijke MySQL-driver naar MySQLi-functies en methoden, maar in zekere zin bega je opnieuw dezelfde fout door alle hardcoded instanties van mysql_-functies te vervangen door hardcoded instanties van het MySQLi-equivalent. Dit is een hoop (foutgevoelig) ge-search en replace in je code. Maar wat nu als je een wrapper had gebruikt voor deze functies? Dan hoefde je (idealiter) enkel de implementatie van deze wrapper aan te passen indien je van de oorspronkelijke MySQL-driver naar MySQLi overstapte. Er zijn andere voordelen van het gebruik van een wrapper: je kunt hier je eigen foutafhandeling en logging in stoppen en ook bewerkingen bundelen (met name bij gebruikmaking van transacties). Ook kun je methode(name)n korter maken zodat communicatie met je database eenvoudiger wordt. En tot slot heb je één plek waar je een uniforme definitie hebt van hoe je met je database communiceert die niet verspreid is over je hele codebase maar is gevangen in één of enkele klassen.


    Het eenmalig schrijven van een wrapper bespaart je op termijn vele malen meer tijd.

  • @FangorN


    Niet per definitie. Je zou natuurlijk gewoon een class kunnen aanmaken en die laten starten op je $mysqli variable.
    Dus:

    Dat is dan weer het voordeel van het object georiënteerd schrijven tegen over procedureel.

  • @MOnkNL ik denk dat we ongeveer hetzelfde bedoelen, je schrijft "wikkels" (wrappers, what's in a name eh?) om de mysqli en mysql_result classes.


    Echter, het uitgangspunt wordt gevormd (of zou gevormf moeten worden) door abstracte classes/interfaces die omschrijven wat de wrappers zouden moeten implementeren om zo te komen tot een soort van semi-uniforme implementatie. Een beetje wat PDO doet dus (je schrijft in wezen een DAAL - Data Access Abstraction Layer).


    Deze wrappers moeten wel een zekere toegevoegde waarde hebben. Dit zijn dus niet enkel aliassen van een mysqli-functie of -methode, dat zou nogal loos zijn (maar wel een stap in de goede richting als het gaat om het tegengaan van "hardcoding van de database-oplossing").


    Wat je bijvoorbeeld zou kunnen doen bij je publieke methode query():
    - nagaan of de query geslaagd was, en
    - zoja, een object van een afgeleide klasse van mysqli_result retourneren (deze kun je ook extenden)
    - de query loggen
    - het aantal queries tellen (+1)
    - zonee, een exception kunnen throwen


    Dit voert dus veel verder dan simpelweg een alias van een mysqli-methode.

Participate now!

Heb je nog geen account? Registreer je nu en word deel van onze community!