Deze komt goed in de database en kan ook inlogen.
Maar als ik deze per mail als $_POST waarde in een html mail plaat, dan komt alleen het volgende door.:
Dat kun je, samen met enkele andere tekens regelen met htmlspecialchars()
[size=xsmall]Toevoeging op 23/01/2025 11:37:32:[/size]
want nu "denkt" je browser of email-client dat daar een html-tag begint.
Stel dat het wachtwoord was abc<br>123
Wat is dan het verschil met "print het wachtwoord abc en dan een enter naar de volgende regel en begin met 123"?
En html-tags mogen spaties gevatten: <div class="foo">, dus een tag loopt door tot de volgende >
In jouw geval heb je niet de afsluitende > staan, dus alles wat verder nog komt, valt onder de tag tot je eindelijk een volgende html-tag aantreft.
Hoezo zou je het escapen, als je het password nog wilt hashen? Je wilt immers niet bepaalde gevaarlijke tekens eerst escapen, zodat je het wachtwoord vernachelt.
Nee.
dat is de verkeerde escaping. Deze functie maakt je string veilig om in de database te zetten. Simpel gezegd: een ' wordt vervangen door \'
Dus in de query komt bij de invoer 'foto's' te staan 'foto\'s'
Vervolgens snapt je database dat die ' voor de s niet het einde van de value is.
Met een <, > of & doet dit niets.
Daarvoor gebruik je htmlspecialchars() om dit veilig in een lap html te plaatsen.
Let wel: bij het plaatsen, niet bij het inserten in je database.
Je wilt namelijk niet < in je database zetten. Leuk om de tekst weer te geven, maar als de gebruiker die < in zijn password invoert, dan is dat niet gelijk aan <
En ook voor andere teksten: je hebt vast wel eens in een tekst in een website of pdf document iets als V&D zien staan: dan wordt op de verkeerde plek de html-escaping toegepast.
[size=xsmall]Toevoeging op 23/01/2025 12:49:50:[/size]
oh, en er is natuurlijk geen reden om een password plain-text op te slaan. Daar zijn genoeg mooie simpele oplossingen voor in php.
