(multiple) output dropdown correct weergeven

Door Johan Steel op 12-10-2020 12:14

3.001 views

Beste forum leden,

Als beginner is het mij gelukt om dropdown menu te maken vanuit een SQL db. Nu zou ik graag zien dat ook meerdere selecties in dit menu te maken zijn. Ook dit is deels gelukt, alleen bij de output wordt slechts 1 gekozen optie weergegeven. Wie kan mij een beetje op weg helpen? Veel dank.


<?php
	include'dbh.php';
?>

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8"/>
	<title>TST</title>
	<link rel="stylesheet" type="text/css" href="style.css">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <link href="https://fonts.googleapis.com/css2?family=Dosis:wght@500&family=Karla:ital@1&family=Nanum+Gothic:wght@700&family=Raleway:wght@300;400&display=swap" rel="stylesheet">
  <style>

  body{
    text-align:center;
    background-color: #EEEEEE;
    }

  .container{
    width:1040px;
    margin: 0px auto;
    overflow: hidden;
    background: white;
   }

  .container header{
    width: 1040px;
    text-align: center;
    margin-top: 10px;
    border-bottom: 1.4px solid  #a9a9a9;
    font-family: 'Karla', sans-serif;
    font-size: 30px;
    color: #242424;
    float: left;
}
  div.item{
    width: 300px;
    height: 220px;
    margin-top: 15px;
    margin-left: 3.5%;
    font-family:  sans-serif;
    display: inline-block;
    font-size: 13px;
    float: left;
      }

  img{
      border-radius: 3%;
      }

    a{
      text-decoration:none;
      color: inherit;
      }


</style>
</head>

<?php
$resultcountry=$conn->query("SELECT DISTINCT country_caught FROM dataset ORDER BY country_caught ASC");
?>

<h1>SEARCH</h1>

<hr/>
<body>
	<form id= method="GET" action="" >
	  <select name="country_caught" multiple >
	    <?php
	    while($rows=$resultcountry->fetch_assoc())
	    {
	        $country=$rows['country_caught'];
	        echo "<option style='display:none'>Country</option>
	              <option value='$country'>$country</option>";
	    }
	    ?>
	  </select>
	 	<button type="submit" name="submit-misc-search" >GO!</button>
	</form>

<hr/>
  <?php

      if(isset($_GET['submit-misc-search'])){
        $country=$_GET['country_caught'];
        $sql1 = "SELECT * FROM dataset WHERE country_caught LIKE '$country' ";
        $result1 =  mysqli_query($conn, $sql1);
        $queryResult1 = mysqli_num_rows($result1);
  ?>

   <body>
  <section class="container">

     <?php
           if($queryResult1 > 0)
           echo
           "<header>
           <p>$country ($queryResult1)</p>
           </header>";

         {
            while($row = mysqli_fetch_assoc($result1)){
                  echo " <div class='item'>
                         <a href='medium/".$row['photo_id'].".jpg'><img src='small/".$row['photo_id'].".jpg'</a><br>
                         </div>";

									 }
						 }
}
					 ?>

 </section>
</html>

- Ariën -

13-10-2020 18:07

Iedereen zijn eigen mening. Maar wat is er mis met de LIKE-operator?

Dit werkt toch prima?

<?php
$sql = "SELECT * FROM Customers
WHERE CustomerName LIKE '".mysqli_real_escape_string($conn, $input)."%'";
?>

Het staat tussen quotes, het heeft niks met LIKE te doen.
Leest alleen een beetje rot met die quotes.

Thomas van den Heuvel

13-10-2020 18:10 gewijzigd op 13-10-2020 18:17

Geen enkele methodiek is veilig als de persoon in kwestie niet weet waar 'ie mee bezig is. Misschien word je wat meer tegen jezelf beschermd met prepared statements, maar onwetendheid is nog steeds geen excuus.

#1 hoe belemmeren quotes het gebruik van numerieke kolommen? je bedoelt het afwezig zijn hiervan? gewoon overal consequent quotes gebruiken en escapen - geen probleem, ook al verandert het datatype. Daarbij, als je de structuur verandert loont het altijd de moeite om code die hierop van toepassing is even langs te lopen? dit zou ik niet blind doen

#2 mja set_charset() is belangrijk, omdat dat bepaalt hoe real_escape_string() werkt; zo zijn de regels van het spel

#3 sja en LIMIT werkt ook niet vlekkeloos in alle gevallen, er zullen altijd uitzonderingen zijn, vind ik niet echt een onoverkomelijk probleem... het is in ieder geval geen reden om een aanpak dan maar helemaal op voorhand af te schrijven

Daarom: weg met mysqli_real_escape_string(), en altijd prepared statements gebruiken.

Het probleem ligt niet bij de methoden die veilig zijn, het probleem ligt bij het gebrek aan kennis over deze concepten. Zelfs als je prepared statements gebruikt zou je nog steeds moeten snappen hoe dit werkt en waarom dit veilig is anders gaat dit gewoon op een gegeven moment nog steeds mis, denk aan concatenatie van SQL/variabelen in een prepared statement.

Daarbij, prepared statements in mysqli zijn onwijs clunky, en in PDO wordt standaard een emulatielaag gebruikt, waarbij niet eens de native support voor prepared statements binnen MySQL wordt gebruikt.

Je zou natuurlijk ook niet enkel de nadruk kunnen leggen op de methodiek, maar ook kunnen kijken wat gewoon prettig werkt. Dit vergt dan misschien wat meer discipline, maar het is waarschijnlijk in het gebruik (stukken) makkelijker.

Kies de aanpak die jou het makkelijkste lijkt, begrijp waarom deze veilig is en kies deze ook vooral op grond van valide argumenten want er circuleert een hoop onzin op het internet over wat "veilig" of "beter" zou zijn.

Onbekende gebruiker

14-10-2020 12:40 gewijzigd op 14-10-2020 12:41

Thomas van den Heuvel op 13/10/2020 18:10:39

Geen enkele methodiek is veilig als de persoon in kwestie niet weet waar 'ie mee bezig is. Misschien word je wat meer tegen jezelf beschermd met prepared statements, maar onwetendheid is nog steeds geen excuus.

Dat is dus het hele punt. Je wordt niet tegen jezelf beschermd. Prepared statements beschermen jou tegen SQL-injectie. mysqli_real_escape_string() doet dat niet, tenzij je zelf altijd enorm oplet.
Daarbij, 'even' langslopen van je code hangt af van hoe effectief je je tijd wilt besteden.
Naarmate het aantal SLOC stijgt, verspil je meer tijd met onnodig langslopen.

Het enige vervelende dat ik had in de tijd dat ik nog aan MySQL vastzat is dat er geen equivalent bestaat voor pg_query_params(). Misschien dat PDO daar iets voor heeft, dat weet ik niet. Maar gelukkig kan je ook zelf een mysqli_query_params() maken. Misschien wel leuk voor bij de PHP Scripts.

- Ariën -

14-10-2020 12:55 gewijzigd op 14-10-2020 12:55

Ad Fundum op 14/10/2020 12:40:35

Dat is dus het hele punt. Je wordt niet tegen jezelf beschermd. Prepared statements beschermen jou tegen SQL-injectie. mysqli_real_escape_string() doet dat niet, tenzij je zelf altijd enorm oplet.

Daarom is het inderdaad de afweging die de programmeur zelf wilt maken. Het is daarom niet dat de escape-functie meteen slecht is.

Als je het vanaf begin af aan consequent op de juiste manier blijft toepassen (quotes, encoding), dan is er niks aan de hand.

Onbekende gebruiker

14-10-2020 13:16 gewijzigd op 14-10-2020 13:18

mysqli_real_escape_string() is neutraal, het doet precies wat het zegt dat het doet.
Wat er slecht aan is, is dat er vaak van gezegd wordt dat het beschermt tegen SQL-injectie.
En dat doet het niet, dat moet je zelf blijven doen.
Tenzij je gebruikt maakt van prepared statements.

Als (beginnend) programmeur kan je vrij snel op het verkeerde been gezet worden, en dat doet afbreuk de filosofie van PHP als zijnde een pragmatische taal. mysqli_real_escape_string() is niet praktisch, het is eerder onhandig. Om de reden die Thomas noemt: je moet al je code in de gaten blijven houden. Dat mensen dan nog er voor kiezen om mysqli_real_escape_string() te willen blijven gebruiken kan ik echt niet volgen.

- Ariën -

14-10-2020 13:41 gewijzigd op 14-10-2020 13:49

Ad Fundum op 14/10/2020 13:16:59

mysqli_real_escape_string() is neutraal, het doet precies wat het zegt dat het doet.
Wat er slecht aan is, is dat er vaak van gezegd wordt dat het beschermt tegen SQL-injectie.
En dat doet het niet, dat moet je zelf blijven doen.

Het helpt theoretisch dan voor 50% procent, kan je zeggen. Je moet zelf netjes de quotes in je query toevoegen waar het moet, maar dat is gewoon weer iets wat je zelf moet aanleren als je MySQL gebruikt. Mis je de quotes, dan denkt MySQL dat het om een veld gaat i.p.v. een string, en als het om een input gaat, dan denkt MySQL dat het onderdeel is van een query. Dus daarom alle input in je query netjes escapen.

Als (beginnend) programmeur kan je vrij snel op het verkeerde been gezet worden, en dat doet afbreuk de filosofie van PHP als zijnde een pragmatische taal. mysqli_real_escape_string() is niet praktisch, het is eerder onhandig. Om de reden die Thomas noemt: je moet al je code in de gaten blijven houden. Dat mensen dan nog er voor kiezen om mysqli_real_escape_string() te willen blijven gebruiken kan ik echt niet volgen.

Als je meer van de prepared statements bent, dan gebruik je dat. Als je beiden (afzonderlijk van elkaar dan) op de juiste manier toepast, dan is de uitkomst uiteindelijk hetzelfde. Het is een keuze die de programmeur zelf moet maken.
Het is niet zo dat het ene inferieur is vergekelen met het andere.

Een slot in een deur moet je ook op de juiste manier inbouwen. Schroef je hem er niet in vast, dan tik je hem er ook zo uit.

Onbekende gebruiker

14-10-2020 15:13 gewijzigd op 14-10-2020 15:14

- Ariën - op 14/10/2020 13:41:55

Een slot in een deur moet je ook op de juiste manier inbouwen. Schroef je hem er niet in vast, dan tik je hem er ook zo uit.

Naar analogie met mysqli_real_escape_string():
Als er dan toch zomaar ineens wordt ingebroken, dan had je van te voren zelf maar zo gis moeten zijn om een slot met kerntrekbeveiliging te gebruiken.
(En een SECU-strip te plaatsen, en een deur met driepuntssluiting te hebben, en je licht aanmoeten houden, en niet op social media moeten zetten dat je een weekje op vakantie was...)

Maar je hebt gelijk: bij goed gebruik kan het goed werken. Als je tijd te veel hebt zou ik zeggen: ga vooral voor mysqli_real_escape_string(), ik hou je niet tegen! :)

Thomas van den Heuvel

14-10-2020 19:54

Ad Fundum op 14/10/2020 15:13:06
Als je tijd te veel hebt zou ik zeggen: ga vooral voor mysqli_real_escape_string(), ik hou je niet tegen! :)

Onbekende gebruiker

14-10-2020 20:11 gewijzigd op 14-10-2020 20:22

Helemaal gelijk Thomas, daarom is er ook zoiets als pg_query_params(), en mysqli_bind_params() (net ff als scriptje toegevoegd).

'Doe het goed, doe het nu'.

Reageren

Inloggen om te reageren