Ik heb een probleempje met het opvullen van een html form binnen php.
Ik lees Mysql variabelen, en probeer ze dan in een form te stoppen
zodanig dat ik ze daarna kan wijzigen.
Echter, de variabele wordt niet correct terug gegeven...
Waarom wil je $row["vnaam"] in $var opslaan?
Wat is je gedachte daarachter?
Als ik een paar goede tip mag geven:
- Je hoeft niet voro elke regel een echo te gebruiken. Een echo werkt ook over meerdere regels, en je kan zelf voor hele lappen HTML zelfs beslissen om je PHP-blok tussentijd te onderbreken met ?> en <?php.
Ook raad ik aan om systematisch altijd $conn->real_escape_string(..) toe te voegen aan alle manipuleerbare variabelen in je query, waaronder $_GET, $_POST, $_COOKIE en $_ENV. Zo voorkom je hacking d.m.v. SQL-injection.
Verder is inline-CSS niet aan te raden, en kan ik een CSS-stylesheet adviseren voor CSS-styling.
Haal je variabelen bij sterke voorkeur altijd buiten je quotes. Je eindig je string met dezelfde quote waarmee je hem begin (single-quote hier in je voorbeeld), en met de punt koppel je er een variabele aan vast. Daarna eindig je het laatste stukje nog met een stujke gekoppelde string.
ECHTER, DIT IS NIET VEILIG / WATERDICHT
Je bent bezig met data weergeven in een HTML-context. Dit betekent dat bepaalde karakters in deze context (denk aan een dubbele quote ("), een openingshaak (<), een sluitingshaak (>), een ampersand (&) et cetera) een speciale betekenis hebben. Vooral als gebruikers invoer verzorgen (user input) is het belangrijk om de deze invoer van (mogelijk) speciale betekenis te ontdoen. Dit doe je met escaping-functies.
Net zoals je in de SQL-context DATA ontdoet van enige speciale betekenis met behulp van escaping-functies zodat deze niet als SQL geïnterpreteerd kan worden (met behulp van de real_escape_string() functie, die overigens NIET veilig is ZONDER het gebruik van quotes) gebruik je in de HTML-context de escaping-functie htmlspecialchars() zodat DATA niet als HTML geïnterpreteerd kan worden.
Een veiliger alternatief zou dus het volgende zijn:
En dan hebben we het nog niet eens over character encoderingen gehad :p. Escaping-functionaliteit werkt namelijk alleen goed als dit wordt gedaan in de gehanteerde character encoding. Als je werkt met encoding A en escapet volgens encoding B dan wordt mogelijk niet alles wat gevaarlijk is geneutraliseerd.
Alles begint eigenlijk bij de bewustwording dat alles een character encodering heeft.
:-)
Ik ben ook slechts enkele weken in deze talen aan het programmeren.
Van opleiding en job ervaring ben ik mainframe programmeur (IBM, DB2, COBOL, PL1, SQL, ...)
Dank je Thomas, ik ga het meteen allemaal uitproberen en hou je op de hoogte.
Filip
[size=xsmall]Toevoeging op 22/05/2017 14:22:29:[/size]
Sorry, heb te snel op button geklikt.
Ben ook nieuw op dit forum, alsook het werken met forums (respons, reacte, ...).
Thanks :-)