fout in me script snap het niet. php7?
Pagina: « vorige 1 2 3 volgende »
Nu is de gebruikersnaam vast gesteld lijkt me ??
Of zie ik dit verkeert?
Toch logt het script nog nu nog steeds niet in.. en komt er nog te staan verkeerde wachtwoord
Debuggen is de eerste oplossing als je merkt dat variabelen niet de juiste waarden geven.
pass uit db... rox
Verkeerd wachtwoord!
Heb het hier met en zonder sleutel het wachtwoord in de data base gezet...
Maar probleem blijft nog steeds .. Er staat nu dan de gebruiker gilbert is zoals eerder de variabel werd op gegeven door :
$naam = 'Gilbert';
$gebrnaam = strtolower(trim($naam));
Nu kan een andere gebruiker niet inloggen nog?
Normaal hoor je gebruiker niet hard-coded in je script te zetten. Ik deed dat enkel vanwege mijn test-case. Dan wil je alles zo compact mogelijk hebben. (plus het feit dat er de sandbox geen mysql-support heeft)
Het lijkt hier fout mee te gaan.
//$gebrnaam = strtolower(mysqli_real_escape_string(trim($_POST['gebruikersnaam'])));
deze regel heb ik even vervangen door:
$gebrnaam = strtolower($_POST['gebruikersnaam']);
Dan werkt het wel .. En is de gebruikersnaam te lezen.. en kunnen meerdere namen inloggen .
Code (php)
1
2
3
2
3
<?php
$gebrnaam = strtolower(mysqli_real_escape_string($con,trim($_POST['gebruikersnaam'])));
?>
$gebrnaam = strtolower(mysqli_real_escape_string($con,trim($_POST['gebruikersnaam'])));
?>
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?
Gewijzigd op 06/08/2018 16:12:41 door Thomas van den Heuvel
- Ariën - op 06/08/2018 14:01:14:
Ik zie wel dat de connectie-parameter mist.
Code (php)
1
2
3
2
3
<?php
$gebrnaam = strtolower(mysqli_real_escape_string($con,trim($_POST['gebruikersnaam'])));
?>
$gebrnaam = strtolower(mysqli_real_escape_string($con,trim($_POST['gebruikersnaam'])));
?>
Jep dat zal de oorzaak zijn..
Toevoeging op 06/08/2018 22:34:47:
>> 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 :-)
- 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.
Toevoeging op 06/08/2018 22:45:08:
- 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:
Code (php)
1
2
3
4
5
6
2
3
4
5
6
<?php
$result = mysqli_query($con, 'SELECT * WHERE 1=1');
if(FALSE === $result) {
$errors[] = 'Fout in query: ' . mysqli_error($con);
}
?>
$result = mysqli_query($con, 'SELECT * WHERE 1=1');
if(FALSE === $result) {
$errors[] = 'Fout in query: ' . mysqli_error($con);
}
?>
Gewijzigd op 06/08/2018 22:55:22 door Frank Nietbelangrijk
Quote:
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.
Quote:
- 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.
Quote:
- 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.
Quote:
- 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.
Quote:
- 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.
Quote:
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
Code (php)
1
2
3
2
3
SELECT *
FROM ...
WHERE <case insensitive kolom> = '<een of andere waarde>'
FROM ...
WHERE <case insensitive kolom> = '<een of andere waarde>'
dan is deze vergelijking automatisch case-insensitive.
Gewijzigd op 06/08/2018 23:25:45 door Thomas van den Heuvel
Thomas van den Heuvel op 06/08/2018 23:23:18:
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.
Quote:
- 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
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.
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.
Pagina: « vorige 1 2 3 volgende »