PHPhulp.nl
35k+ leden Over PHPhulp Offerte opdracht Contact
n

fout in me script snap het niet. php7?

Door nilix bies op 05-08-2018 17:44 gewijzigd op 05-08-2018 17:54
7.216 views
Beste iedereen.

Ik hoop dat hier een paar php freaks zijn die mij kunnen helpen

Ik beheer een kleine website voor onze fotoclub. Nu is de webhosting in eens over gegaan naar php7.
Hier door werken enkele scripts niet meer ik heb de meeste weer goed gekregen door aan passingen. Maar net de inlog script voor leden werkt niet meer.
Mijn mysql data base is goed daar worden wel gegeven uit opgehaald op een andere test pagina en voor de portfolio's


Na het inloggen komt er gelijk een fout.
Hier door komt er ook een stuk van het scrip in beeld wat normaal niet zou kunnen
Dit zie ik in beeld staan:

Fout: ingevoerd gebruikersnaam klopt niet!</p>";
}else{ //mailadres staat in de database, we gaan verder!
while($record = mysqli_fetch_object($ophalen)){
$password_db = $record->wachtwoord;

}


---------------------------------------
Ik weet niet of het nu wel mag maar hier onder mijn script wat is er fout?

<?
session_start();




if ($_POST['submit']=="login")
{
include "log.php";

$gebrnaam ==(strtolower ( $_POST['gebruikersnaam']));

$sql = "SELECT * FROM `leden` WHERE `gebruikersnaam` = '".$_POST['gebruikersnaam']."'";

$ophalen = mysqli_query($con, $sql);
$aantal = mysqli_num_rows($ophalen); // aantal records met verstuurd emailadres tellen

if($aantal == 0){

echo"<p>Fout: ingevoerd gebruikersnaam klopt niet!</p>";

}else{

//mailadres staat in de database, we gaan verder!

while($record = mysqli_fetch_object($ophalen)){
$password_db = $record->wachtwoord;

}

//password nu vergelijken met ingevoerd password

if($password_db != $_POST['wachtwoord']){

echo"<p>Verkeerd wachtwoord!</p>";

}else{

//email staat in database en password klopt, sessie starten!

while($record = mysqli_fetch_object($ophalen)){
$id = $record->id;}

//sessie opstarten

$idlog=(strtolower ($_POST['gebruikersnaam']));


$_SESSION["idlog"]= $idlog;

if ($idlog == "admin"){

echo "<meta http-equiv=REFRESH content=0;url=adm.php?idlog=". $_POST['gebruikersnaam'] . " target=main> ";

}
else{
echo "gelukt ";

$datenu=date("d-m-y");

mysqli_query ($con, "UPDATE leden SET datenu='$datenu' WHERE gebruikersnaam='$idlog'");

echo "<meta http-equiv=REFRESH content=0;url=loginstart.php?idlog=". $_POST['gebruikersnaam'] . " target=main> ";
}

}
}

}

?>

<head>
<link a href="instel.css"rel="stylesheet"type="text/css" />
</head>
<body class=body>

<?php include("top.php");
?>


<table align=center width=1100><tr><font color=white size=4 face=calibri>
<td align=center >



<font color=white size=4 face=calibri>



<form method="post" action="login.php">
<table width=300 border=1 cellpadding=3 cellspacing=1 align=center >
<tr>

<td colspan=2>
<font color=white size=4 face=calibri> Login leden fotoclub</td>
</tr><tr>
<td align=right>
<font color=white size=4 face=calibri> Loginnaam:
</td>

<td> <input type=text name=gebruikersnaam> </td></tr><tr>
<td align=right>
<font color=white size=4 face=calibri>&nbsp Wachtwoord:</td
>
<td> <input type=password name=wachtwoord></td></tr><tr>

<td colspan=2 align=center><br> <input type="submit" name="submit" value="login">
</td></tr></table>
</form>

<br><BR>
Ik weet mijn login gegevens niet meer? <a href=vergeten.php target=home>Klik hier</a>
</td>
Thomas van den Heuvel
06-08-2018 16:12 gewijzigd op 06-08-2018 16:12
Escaping voor een specifieke context is altijd de laatste bewerking die je uit zou moeten voeren. Oftewel, eerst prepareer je de data zoals je die zou willen hebben, en dan escape je pas.

Aan de andere kant, die strtolower en trim zijn nogal loos niet? Het is aan de gebruiker om zijn/haar gebruikersnaam goed in te typen. Is er een specifieke reden om trim en strtolower te gebruiken, of heb je (de topicstarter) dit ergens vandaan geknipt en geplakt zonder er echt over na te denken?
Frank Nietbelangrijk
06-08-2018 22:29
- Ariën - op 06/08/2018 14:01:14

Ik zie wel dat de connectie-parameter mist.


<?php
$gebrnaam = strtolower(mysqli_real_escape_string($con,trim($_POST['gebruikersnaam'])));
?>



Jep dat zal de oorzaak zijn..



[size=xsmall]Toevoeging op 06/08/2018 22:34:47:[/size]

>> Aan de andere kant, die strtolower en trim zijn nogal loos niet?

Dat vind ik dan persoonlijk weer een kwestie van smaak. Het mag strtolower als je dat wilt maar is niet verplicht. Je bereikt er mee dat 'GeBrUiKeRsNaAm' doorgaat als 'gebruikersnaam' Nilix mag zich afvragen of hij (of zij) dat wil. trim haalt een eventuele spatie voor of achter de gebruikersnaam weg. Dit bespaart verwarring bij de gebruikers die 50+ zijn :-)
- Ariën -
06-08-2018 22:35
Maar anders had je vast wel een error moeten krijgen. Dus als je niks ziet, dan is je fouten-rapportage niet aanwezig, en dat is niet handig tijdens het ontwikkelen.
Frank Nietbelangrijk
06-08-2018 22:38 gewijzigd op 06-08-2018 22:55
Het kan overigens geen kwaad om een keer goed over het begrip gebruikersnaam na te denken.

- Moet een gebruikersnaam uniek zijn?
- Wat nou als je twee gebruikers hebt die dezelfde gebruikersnaam gebruiken?
- en wat nou als die twee gebruikers met dezelfde naam ook nog hetzelfde wachtwoord gebruiken ?
- Of laat ik gebruikers uitsluitend met een emailadres inloggen welke dan wel uniek moet zijn?

Allemaal leuke hersenkrakers.

[size=xsmall]Toevoeging op 06/08/2018 22:45:08:[/size]

- Ariën - op 06/08/2018 22:35:39

Maar anders had je vast wel een error moeten krijgen. Dus als je niks ziet, dan is je fouten-rapportage niet aanwezig, en dat is niet handig tijdens het ontwikkelen.


Das dus ook al een hoofdstuk apart. Neem nou de functie mysqli_query(). Op php.net kun je lezen dat deze functie ook een FALSE terug kan geven als er iets foutgaat (Wat ook heel erg makkelijk kan gebeuren). Als je dat niet afvangt in je code dan zal je applicatie op een van de volgende regels fouten gaan genereren.

Voorbeeld:
<?php
$result = mysqli_query($con, 'SELECT * WHERE 1=1');
if(FALSE === $result) {
$errors[] = 'Fout in query: ' . mysqli_error($con);
}
?>
Thomas van den Heuvel
06-08-2018 23:23 gewijzigd op 06-08-2018 23:25
Dat vind ik dan persoonlijk weer een kwestie van smaak. Het mag strtolower als je dat wilt maar is niet verplicht. Je bereikt er mee dat 'GeBrUiKeRsNaAm' doorgaat als 'gebruikersnaam' Nilix mag zich afvragen of hij (of zij) dat wil. trim haalt een eventuele spatie voor of achter de gebruikersnaam weg. Dit bespaart verwarring bij de gebruikers die 50+ zijn :-)

Dat is ook een kwestie van smaak. Naar mijn mening zijn strtolower() en trim() in dit geval bewerkingen die recht proberen te buigen wat krom is. Een gebruikersnaam met teveel spaties aan het begin en aan het einde is naar alle waarschijnlijkheid gewoon verkeerde invoer, verkeerde invoer moet je niet proberen te repareren, verkeerde invoer moet je gewoon afkeuren.

- Moet een gebruikersnaam uniek zijn?

Dat is eigenlijk een verkeerde vraag. De juiste vraag is eigenlijk: wat gebruik ik in mijn systeem om gebruikers van elkaar te onderscheiden / uniek te identificeren. In bijna alle gevallen is dat een of andere entiteit die iemand uniek maakt, zoals een (unieke) gebruikersnaam, een e-mailadres, een abonneenummer etc.

- Wat nou als je twee gebruikers hebt die dezelfde gebruikersnaam gebruiken?

Vanuit een gebruikersperspectief is dat verwarrend en vanuit een ontwerperspectief is dat niet zo'n fantastische keuze. Dit is dus een situatie die je gewoon wilt vermijden, vooral als de gebruikersnaam een gebruiker uniek zou moeten identificeren.

- en wat nou als die twee gebruikers met dezelfde naam ook nog hetzelfde wachtwoord gebruiken ?

Dezelfde namen is iets wat je zou moeten vermijden, hetzelfde wachtwoord maakt echt geen biet uit.

- Of laat ik gebruikers uitsluitend met een emailadres inloggen welke dan wel uniek moet zijn?

Dat is ook een mogelijkheid, maar wat je als identificerende entiteit gebruikt hangt mede af van het systeem dat je bouwt.

Allemaal leuke hersenkrakers.

Mja, als je iets eerst ontwerpt en dan bouwt is het makkelijker om van ongewenste sitiaties weg te sturen. Als je meteen begint met code kloppen sta je meestal na verloop van tijd gewoon vast in de (je eigen) modder.

Dat gezegd hebbende, als je een gebruikersnaam als identificerend attribuut hebt, zou ik deze nog steeds case-insensitive opslaan en controles case-insensitive uitvoeren. Immers, als iemand zich registreert als gebruiker "HENK" terwijl er al een gebruiker "Henk" in je database zit, dan wil je deze tweede persoon vriendelijk verzoeken om zijn (of haar :)) naam aan te passen, omdat "HENK" (case-insensitive) al in gebruik is.

Misschien realiseren mensen zich dit niet eens maar als je zoiets doet als
SELECT *
FROM ...
WHERE <case insensitive kolom> = '<een of andere waarde>'

dan is deze vergelijking automatisch case-insensitive.
? Onbekende gebruiker
07-08-2018 12:39
Thomas van den Heuvel op 06/08/2018 23:23:18

- Wat nou als je twee gebruikers hebt die dezelfde gebruikersnaam gebruiken?

Vanuit een gebruikersperspectief is dat verwarrend en vanuit een ontwerperspectief is dat niet zo'n fantastische keuze. Dit is dus een situatie die je gewoon wilt vermijden, vooral als de gebruikersnaam een gebruiker uniek zou moeten identificeren.

Wanneer de gebruikersnamen uniek zijn maakt het inderdaad geen biet uit of de wachtwoorden gelijk zijn. Maar wanneer de gebruikersnamen niet uniek zijn is het verhaal al heel anders.

Zoek de verschillen:
piet met wachtwoord abc
piet met wachtwoord abc
piet met wachtwoord abc

Dus als je niet unieke gebruikersnamen toe staat moeten de wachtwoorden uniek zijn anders krijg je nog steeds geen uniek resultaat
Thomas van den Heuvel
07-08-2018 14:39
Mja, maar dat is zoiets als:

Dus als je <een onhandige constructie toepast> dan <moet je je in allerlei rare bochten wringen>.

De notie om dan maar het wachtwoord uniek te maken is op zijn zachtst gezegd redelijk krankjorem. Hoe ga je dit afdwingen? Krijgt de gebruiker bij wijziging hiervan een melding "Sorry, dit wachtwoord is al in gebruik?". En wat als iemand niet meer bij zijn account kan, hoe gaat dat dan werken? Een e-mailadres zou dan nog uitkomst kunnen bieden.

Misschien is het handig om ook onderscheid te maken in welke betekenis je "gebruikersnaam" gebruikt:
- een publieke naam waaronder jij bij andere gebruikers bekend staat
- de naam waarmee je jezelf authenticeert bij een loginsysteem

In beide gevallen is het niet handig (of simpelweg onmogelijk tenzij je voortborduurt op dit slechte ontwerp) dat dit soort, of sterk gelijkende, namen niet uniek zijn.

Je zou zelfs zo ver kunnen gaan dat je zowel "gebruikersnaam" als e-mailadres (los van elkaar) de verplichting oplegt dat deze beide uniek zouden moeten zijn. Dit voorkomt zoveel gezeik down the road op het moment dat je een groot ledensysteem krijgt, zowel voor beheer als gebruik door eindgebruikers zelf.
? Onbekende gebruiker
07-08-2018 16:13
Ik zeg ook niet dat het een juiste methode is, maar als je niet controleert bij de aanmelding of de gebruikersnaam al bestaat moet je wel wat
Thomas van den Heuvel
07-08-2018 16:55
Bernhard Flokstra op 07/08/2018 16:13:42
maar als je niet controleert bij de aanmelding of de gebruikersnaam al bestaat

Daar ontstaat het probleem, dus daar moet je het ook oplossen.
Frank Nietbelangrijk
07-08-2018 17:12
Hey Thomas bedankt voor de bijdrage. Mijn bericht was vooral bedoeld richting de Topic starter welke waarschijnlijk niet zo veel ervaring heeft als jij. Ik probeer bij de starters een denkproces te starten. Dat is - denk ik - het meest zinvol. In dit geval was de bedoeling om Nilix na te laten denken over het 'gegarandeerd juist onderscheiden' van verschillende gebruikers in zijn applicatie :-O

Reageren

Inloggen om te reageren