'Wachtwoord vergeten' werkt niet (resetten)

Door Hans De Ridder op 05-12-2017 15:02

5.809 views

Mijn script om een wachtwoord te resetten werkt het laatste stukje niet van.
Gaat waarschijnlijk om de functie function Reset_Password.
Hij ziet het 'process' niet waardoor er geen reset plaatsvindt.
Het sturen van de email gaat prima.
De code wordt netjes opgeslagen.
Komt ook overeen met de code die per email werd opgenomen.
Er wordt netjes overgeschakeld om het nieuwe wachtwoord in te vullen.
En dan houdt het op.
Want komt if(isset($process)) niet door.
Heb al van alles geprobeerd. Maar ik vind geen vreemde zaken.
Zelfde gebeurt ook bij 'Gebruikersnaam vergeten'.

Iemand advies?
Hier belangrijkste stukken uit de scripts:

PAGINA FORGOT_PASSWORD:


<?php
include_once 'processes.php';
$Login_Process = new Login_Process;
$Check = $Login_Process->Forgot_Password($_GET, $_POST);
$Request = $Login_Process->Request_Password($_POST, $_POST['Request']);
$Reset = $Login_Process->Reset_Password($_POST, $_POST['Reset']);
?>
<body>
<?php 
switch($Check) {
	case "<!-- !-->":
?>
<form action= <?php echo $_SERVER['PHP_SELF']; ?> method="post">
<input name="code" type="hidden" id="code" value="<?php $_GET['code']; ?>" >
<input name="Reset" type="submit" value="Reset wachtwoord" id="Reset">
</form>
<?php 
		break;
	default:
?>
<form action= <?php echo $_SERVER['PHP_SELF']; ?> method="post">
<input name="Request" type="submit" value="Verzoek email reset wachtwoord" id="Request"/>
</form>
<?php 
}
?>

VERWERKING IN PROCESSES:


function Forgot_Password($get, $post) {
	
	$code = $_POST['code'];
	if(!$code) { 
	$code = $_GET['code']; } 

$code2 = $i->get(CODE);
if ($code === $code2)
{
return "<!-- !-->";
break;
}
}

function Request_Password($post, $process) {
		
	if(isset($process)) {

echo $i->set(CODE,$code); 

Mail_Reset_Password($name, $code, $email);
				return "Er is een email verstuurd. Hiermee kun je het wachtwoord resetten.";
}
}

function Reset_Password($post, $process) {

		if(isset($process)) {	
$code = "";
$password_hash = $pass1;
echo $i->set(CODE,$code); 
echo $i->set(PASSWORD_HASH,$password_hash); 

Mail_Reset_Password_Confirmation($name, $email);
return "Wachtwoord is gewijzigd. Je kunt nu inloggen.";
}
}

[size=xsmall]Toevoeging op 05/12/2017 15:11:47:[/size]

Eindelijk gevonden na het doorlezen van mijn topic...
Was de echo vergeten bij $_GET.....

Ben van Velzen

06-12-2017 17:28

Nogmaals: lees de opmerkingen nog eens door. Doe dat ook meteen even met de opmerkingen over espacing on output. Ik mis een hoop htmlspecialchars of htmlentities, en de genoemde PHP_SELF staat er nog steeds in.

Ariën

06-12-2017 18:52

En ik ben ook erg benieuwd naar de reden van die


return "<!-- !-->";

Daar kunnen we dan vast wel een gepastere oplossing voor geven.

Hans De Ridder

06-12-2017 19:47

Dit gedeelte zorgt er voor dat alle returns (foutmeldingen, opmerkingen, etc.)
terecht komen in de bij elke pagina aanwezige div 'red'.
Bij elke return wordt de pagina herladen.
Bij de return "" gebeurt hetzelfde.
Bij het herladen wordt er weer gekeken naar $Check en wordt het andere deel getoond
van de pagina. Denk dat het zo ongeveer werkt.

Ben nu aan het studeren wat ik nu moet verstaan onder uitgangen.
Ik heb tot nu toe aangenomen dat hetgene wat ik zelf laat neerzetten in beeld
een uitgang is.
Ingangen gaan door de validatie en dan wordt het opgeslagen.
Bij het uitlezen gebruik ik dan wat code om de data schoon te maken.
Maar die interpretatie gaat niet op, merk ik aan sommige reacties.
Bovendien zijn er nogal wat (slechte) voorbeelden.
Misschien is er iemand die de pagina van het inloggen wat kan vertimmeren als voorbeeld?


$Login_Process = new Login_Process;
$Check = $Login_Process->Forgot_Password($_GET, $_POST);
$Request = $Login_Process->Request_Password($_POST, $_POST['Request']);
$Reset = $Login_Process->Reset_Password($_POST, $_POST['Reset']);

Ariën

06-12-2017 19:55

Zoals al eerder werd geopperd: $_POST en $_GET zijn superglobals, en hoef je niet speciaal beschikbaar te maken voor in een functie door ze als argument mee te geven.

Hans De Ridder

06-12-2017 21:16 gewijzigd op 06-12-2017 21:16

Ik heb even snel gekeken.
Zit ook nog foutje in.
Want het nieuwe wachtwoord invullen gebeurt nu op nieuwe pagina.
Zodat er ineens twee pagina's open staan.
Het maakt wel uit of ik die regels gebruik.
Bij de $Check ging het goed.
Bij de andere wel de tweede $_POST['Request'] en $_POST[$_POST['Reset'] laten staan even.


$Check = $Login_Process->Forgot_Password();
$Request = $Login_Process->Request_Password($_POST['Request']);
$Reset = $Login_Process->Reset_Password($_POST['Reset']);

Het had tot gevolg dat de nieuwe inputs geen waardes doorgaven meer.
Verder nog niet naar de oorzaak gekeken.

[size=xsmall]Toevoeging op 07/12/2017 00:31:23:[/size]

Ik heb de data nu verwijderd.
Het zou kunnen werken.
Alleen wordt de $Request nu direct gesubmit.
Er kwam bijv. direct de melding dat de email niet ingevuld was.
Dat kan pas na het posten.


$Check = $Login_Process->Forgot_Password();
$Request = $Login_Process->Request_Password();
$Reset = $Login_Process->Reset_Password();

[size=xsmall]Toevoeging op 07/12/2017 01:13:55:[/size]

Als volgt gewijzigd en werkend.
Maar nog wel met extra pagina:


function Forgot_Password() {
........
}

function Request_Password() {
	if(isset($_POST['Request'])) 
  {		
  ....
  }
}

function Reset_Password() {

		if(isset($_POST['Reset'])) 
  {
  ....
  }
}

EN OP DE PAGINA


$Check = $Login_Process->Forgot_Password();
$Request = $Login_Process->Request_Password();
$Reset = $Login_Process->Reset_Password();

Hans De Ridder

08-12-2017 00:01

Ik heb het nu zo geregeld dat na 5 seconden de location wijzigt, waar de inlogpagina staat.
Dus dat is nu klaar.

Misschien is er nog iemand die een voorbeeld kan geven over de in- en outputs.
Lees daar verschillend over oforums.
Gaat dan over gewone forminputs.
En over de pagina's waar info gegeven wordt via de inputs <?php echo $t ?>
Waar de een scriptje heeft vult een ander weer wat anders in.

[code]
// define variables and set to empty values
$name = $email = $gender = $comment = $website = "";

if ($_SERVER["REQUEST_METHOD"] == "POST") {
$name = test_input($_POST["name"]);
$email = test_input($_POST["email"]);
$website = test_input($_POST["website"]);
$comment = test_input($_POST["comment"]);
$gender = test_input($_POST["gender"]);
}

function test_input($data) {
$data = trim($data);
$data = stripslashes($data);
$data = htmlspecialchars($data);
return $data;
}

<form method="post" action="<?php echo htmlspecialchars($_SERVER["PHP_SELF"]);?>">

<form method="post" action="<?php echo htmlentities($_SERVER["PHP_SELF"]);?>">

PS reactie kan wat later komen... Ben paar dagen weg.

Ben van Velzen

08-12-2017 00:23

PHP_SELF moet je gewoon helemaal niet gebruiken, ongeacht de escaping.
De test_input functie moet je gewoon weggooien, kun je niks mee. Ook gewoon niet zoiets doen dus.
Output is alles dat naar het scherm gegooid of je database gegooid wordt. Geen enkele variabele is betrouwbaar:
<?php
echo 'Dit is tekst die naar de browser gaat, met een GET: ' . htmlspecialchars($_GET['test']);
$sql = "SELECT title, description FROM test WHERE id = '" . mysqli_real_escape_string($db, $_GET['test']) . "'";
// hier je query
?>
Je ziet hier al heel duidelijk waarom je je data niet onschadelijk moet proberen te maken. Verschillende doelen hebben verschillende eisen voor escaping.

Nogmaals: haal die test_input functie weg, doe zoiets NIET, NOOIT, NEVER. Alleen als je het idee al krijgt om zo'n functie te gebruiken moet je jezelf een klap geven. Stripslashes heb je sowieso nooit nodig, htmlspecialchars is alleen voor output. trim is eventueel nuttig, maar alleen voor de input waar dat voor geldt.

Input valideer je, maar muteer je niet. De enige mogelijke uitzondering is trim, maar dat is ook echt het enige. Je controleert dus of iets minimaal 3 tekens is, uit getallen bestaat, etc etc.

Hans De Ridder

08-12-2017 00:39

Bedankt Ben...

Begrijp ik het dan goed dat je in de form gebuikersinputs alleen valideert?
Daar worden de controles uitgevoerd waar een gegeven input aan moet voldoen.
Cijfers, letters, verboden tekens, bepaalde woorden bevattend, etc.)
En datgene wat in beeld verschijnt htmlspecialchars() doet.
En bij de $_GET ook htmlspecialchars()
En waar ergens in de form een action staat daar een htmlentities() wordt gedaan.

Ik gebruik (nog) geen gewone database.
Wel opslag van gegevens.

Ben van Velzen

08-12-2017 01:04

Bij alle variabelen van buitenaf pas je escaping toe bij uitvoer, of dat nu POST, GET, COOKIE of SERVER is, of een afgeleide eigen variabele (ja, $_SERVER komt van buitenaf en is daarmee dus ook niet betrouwbaar).
Voor jouw geval zul je moeten kijken welke escaping vereisten er zijn voor iptc, vermoedelijk is het helemaal niets omdat het pure metadata opslag is die niet geschikt is voor dataverwerking. Je vuurt er geen queries op af, het is puur data.

In de form kun je ook gewoon htmlspecialchars gebruiken of htmlentities, maar nog liever urlencode. Zet echter NOOIT PHP_SELF in je action, deze is te makkelijk beinvloedbaar. Wanneer je naar dezelfde pagina wilt verwijzen als waar je toch al bent gebruik je gewoon een leeg action attribuut.

Input valideer je alleen. Je controleert of het van het correcte formaat is (cijfers, letters, TOEGESTANE tekens, controleer nooit aan de hand van een blacklist maar met een whitelist). De data gaat zo ruw mogelijk naar opslag, dit kun je bij output altijd weer rechttrekken.

Thomas van den Heuvel

08-12-2017 03:16

Ben van Velzen op 08/12/2017 01:04:40
$_SERVER komt van buitenaf en is daarmee dus ook niet betrouwbaar.

Toch alleen de HTTP_* directives? Of nog meer? Desalniettemin blijft het een goede gewoonte om al deze data niet te vertrouwen, en dus te escapen.

Ben van Velzen op 08/12/2017 01:04:40
In de form kun je ook gewoon htmlspecialchars gebruiken of htmlentities, maar nog liever urlencode.

Die volg ik even niet? $_POST en $_GET worden automatische ge-urldecode(). Het enige wat je ooit zou moeten encoden zijn (keys en values) van de querystring in een URL voor de action, maar voor de rest toch niet?

Ben van Velzen op 08/12/2017 01:04:40
Zet echter NOOIT PHP_SELF in je action, deze is te makkelijk beinvloedbaar.

Maakte iemand hier laatst geen opmerking over, dat je veel beter SCRIPT_NAME (of iets anders?) kon gebruiken, omdat deze om te beginnen al een stuk minder corrumpeerbaar was? Nog steeds escapen. Of zelf handmatig de URL opbouwen. En dan nog steeds escapen :).

Reageren

Inloggen om te reageren