Login Class
Door Jelle Posthuma, 19 jaar geleden, 7.614x bekeken
Een login class voor een uitgebreid login systeem.
Gesponsorde koppelingen
PHP script bestanden
Er zijn 19 reacties op 'Login class'
Gesponsorde koppelingen
Mag ik vragen waarom je voor iets simpels als een login 4 cookies gebruikt?
Het opslaan van usernames en wachtwoorden in cookies is IMO echt een no go!
(Doet deze site ook, maar daarom is het nog niet goed!)
Vincent had hier een goed artikel over, maar die is helaas met z'n site bezig zo te zien.
Het idee is meer dat je alleen bij de daadwerkelijke login de gebruikersnaam en het wachtwoord hoeft te controleren. Aan de hand hiervan kan je een mooie hash maken welke je in de cookie opslaat en in de database (doe je al).
Tesamen met een ip adres en wellicht nog wat andere info kan je vaststellen dat iemand ingelogt dient te zijn.
Wachtwoorden en usernames in cookies zijn echt niet nodig en een groot beveiligings gevaar!
Verder vind ik dit script niet echt gevorderd om het zo maar te noemen.
Maar hoop dat je wat aan mijn kritiek hebt.
Het opslaan van usernames en wachtwoorden in cookies is IMO echt een no go!
(Doet deze site ook, maar daarom is het nog niet goed!)
Vincent had hier een goed artikel over, maar die is helaas met z'n site bezig zo te zien.
Het idee is meer dat je alleen bij de daadwerkelijke login de gebruikersnaam en het wachtwoord hoeft te controleren. Aan de hand hiervan kan je een mooie hash maken welke je in de cookie opslaat en in de database (doe je al).
Tesamen met een ip adres en wellicht nog wat andere info kan je vaststellen dat iemand ingelogt dient te zijn.
Wachtwoorden en usernames in cookies zijn echt niet nodig en een groot beveiligings gevaar!
Verder vind ik dit script niet echt gevorderd om het zo maar te noemen.
Maar hoop dat je wat aan mijn kritiek hebt.
@lode,
Sterker nog. Die hash sla je niet op in een cookie maar in een sessie. Je maakt een aparte tabel in je database aan genaamd 'blijfIngelogd". Hierin kun je een ANDERE hash neerzetten die je gebruikt in de cookie.
Je zet dus een sessie met een unieke hash, deze hash sla je in de database op in de tabel "ingelogd" met de velden "userId" en "sessieHash".
Wanneer een bezoeker het vakje "blijf ingelogd' heeft aangevinkt zet je een cookie met een hash en diezelfde hash sla je op in de tabel "BlijfIngelogd" met de velden "userId" en "sessieHash".
Wanneer een bezoeker nu een pagina bezoekt kijk je of de hash overeenkomt met een hash in je database. Zo ja dan is de bezoeker ingelogd, zo nee dan check je of er een cookie is met een hash die overeenkomt met een hash in je database. Is dat zo dan is de bezoeker ingelogd. Je set een sessie met een nieuwe hash, verandert de hash van de cookie en hoeft volgende keer niet meer naar een cookie te vragen.
Op die manier kun je ook het probleem voorkomen met iemand die cookies uit heeft staan.
Sterker nog. Die hash sla je niet op in een cookie maar in een sessie. Je maakt een aparte tabel in je database aan genaamd 'blijfIngelogd". Hierin kun je een ANDERE hash neerzetten die je gebruikt in de cookie.
Je zet dus een sessie met een unieke hash, deze hash sla je in de database op in de tabel "ingelogd" met de velden "userId" en "sessieHash".
Wanneer een bezoeker het vakje "blijf ingelogd' heeft aangevinkt zet je een cookie met een hash en diezelfde hash sla je op in de tabel "BlijfIngelogd" met de velden "userId" en "sessieHash".
Wanneer een bezoeker nu een pagina bezoekt kijk je of de hash overeenkomt met een hash in je database. Zo ja dan is de bezoeker ingelogd, zo nee dan check je of er een cookie is met een hash die overeenkomt met een hash in je database. Is dat zo dan is de bezoeker ingelogd. Je set een sessie met een nieuwe hash, verandert de hash van de cookie en hoeft volgende keer niet meer naar een cookie te vragen.
Op die manier kun je ook het probleem voorkomen met iemand die cookies uit heeft staan.
edit:
En uiteraard check je ook nog het IP in de database
Ik sla voor de zekerheid toch altijd nog wat andere dingen encrypted array'tje op in de cookie met een base16, 32 of 64 eroverheen, voor de url vriendelijkheid. En inderdaad dat is dan dus weer een andere hash als de lokale ;)
maar wachtwoorden in cookies dat kan echt niet meer!
EDIT, nee een functie die gewoon maar een bool returned is niet zo nuttig ook, maar ik dacht ik houd het maar eens bij het belangrijkste. Genoeg verwijten gehad hier...
maar wachtwoorden in cookies dat kan echt niet meer!
EDIT, nee een functie die gewoon maar een bool returned is niet zo nuttig ook, maar ik dacht ik houd het maar eens bij het belangrijkste. Genoeg verwijten gehad hier...
wachtwoorden en cookies gaan idd niet samen!
maar dit slaat hellemaal nergens Op!
je doet nix ! :S je returnd alleen false of true
Code (php)
maar dit slaat hellemaal nergens Op!
je doet nix ! :S je returnd alleen false of true
@ rvw en webmakerij:
mss dat hij de functie als dummy gebruikt en dat ie deze later gaat afmaken of juist deze functie heeft vervangen door een ander.
wat zijn de mensen toch weer goed in afkraken. Er is een verschil tussen opbouwende kritiek en afkraken. Het verschil daartussen wordt volgens mij niet door veel mensen hier gesnapt.
Wat je er ook van vindt, je kan het tenminste op een vriendelijke manier duidelijk maken ipv. de maker af te blaffen om wat slordigheden.
Dat afblaffen demotiveert de maker en zal voorkomen dat de maker zijn code zal verbeteren. Opbouwende kritiek zal juist motiveren en zo zullen er meerdere (goede) scripts komen.
mss dat hij de functie als dummy gebruikt en dat ie deze later gaat afmaken of juist deze functie heeft vervangen door een ander.
wat zijn de mensen toch weer goed in afkraken. Er is een verschil tussen opbouwende kritiek en afkraken. Het verschil daartussen wordt volgens mij niet door veel mensen hier gesnapt.
Wat je er ook van vindt, je kan het tenminste op een vriendelijke manier duidelijk maken ipv. de maker af te blaffen om wat slordigheden.
Dat afblaffen demotiveert de maker en zal voorkomen dat de maker zijn code zal verbeteren. Opbouwende kritiek zal juist motiveren en zo zullen er meerdere (goede) scripts komen.
@toby
Oké misschien had ik het wat opbouwender kunnen brengen.
Als het is zo als jij het zegt dat hij het nog gaat afmaken is dat en slechte zaak ja toch ? je post toch pas en script als het af is...
met en read of set funtie zet je waarde of lees je waarde uit.
zo better toby :)
Oké misschien had ik het wat opbouwender kunnen brengen.
Als het is zo als jij het zegt dat hij het nog gaat afmaken is dat en slechte zaak ja toch ? je post toch pas en script als het af is...
Code (php)
met en read of set funtie zet je waarde of lees je waarde uit.
zo better toby :)
Over die functies waar alleen maar booleans gereturned worden, daar ga ik nog naar uitbreiden.
Maar wou eerst weten of de class zo een beetje netjes is.
Over die hashes en cookies, ik zal vanavond eens kijken naar de tip van PHP Newbie.
Neem aan dat als ik dat doorgevoerd heb, dat het er dan wel op begint te lijken, toch?
Maar wou eerst weten of de class zo een beetje netjes is.
Over die hashes en cookies, ik zal vanavond eens kijken naar de tip van PHP Newbie.
Neem aan dat als ik dat doorgevoerd heb, dat het er dan wel op begint te lijken, toch?
Wellicht iets offtopic:
Waarom 2x een wachtwoord (-hash) opslaan? 1x de hash (md5 of sha1) opslaan is meer dan genoeg, daar kun je alle vergelijkingen mee doen die je ooit zou willen doen. Het echte wachtwoord wil je niet weten en/of opslaan, dat kan alleen maar voor veiligheidsproblemen zorgen.
Verder is een md5-hash altijd 32 karakters en een sha1 altijd 40 karakters, een CHAR(32) of CHAR(40) zijn dan ook de aangewezen datatypes voor deze hashes.
MyISAM zal wel een foutje zijn, daarmee kun je geen relationele database bouwen en onderhouden. De DBMS (kuch!) is niet in staat om relaties te onderhouden...
Cookies die zonder enige vorm van beveiliging in een query worden gezet, zorgen natuurlijk voor een gigantisch veiligheidslek, het hele inloggen wordt daarmee volkomen overbodig. Met een beetje SQL-injection kan ieder hackertje inloggen zonder wachtwoorden en/of userid's. Gebruik mysql_real_escape_string() om dit tegen te gaan.
Waarom 2x een wachtwoord (-hash) opslaan? 1x de hash (md5 of sha1) opslaan is meer dan genoeg, daar kun je alle vergelijkingen mee doen die je ooit zou willen doen. Het echte wachtwoord wil je niet weten en/of opslaan, dat kan alleen maar voor veiligheidsproblemen zorgen.
Verder is een md5-hash altijd 32 karakters en een sha1 altijd 40 karakters, een CHAR(32) of CHAR(40) zijn dan ook de aangewezen datatypes voor deze hashes.
MyISAM zal wel een foutje zijn, daarmee kun je geen relationele database bouwen en onderhouden. De DBMS (kuch!) is niet in staat om relaties te onderhouden...
Cookies die zonder enige vorm van beveiliging in een query worden gezet, zorgen natuurlijk voor een gigantisch veiligheidslek, het hele inloggen wordt daarmee volkomen overbodig. Met een beetje SQL-injection kan ieder hackertje inloggen zonder wachtwoorden en/of userid's. Gebruik mysql_real_escape_string() om dit tegen te gaan.
Quote:
Deze class heb ik gemaakt met beperkte kennis van classes, en deze plaats ik hier voor jullie, en om deze te laten controleren.
Zit deze class goed in elkaar?
En wat kan eraan verbeterd worden?
Mijn verstand van classes is nog licht beperkt, dus hier heb ik alleen basis elementen in gebruik.
Zit deze class goed in elkaar?
En wat kan eraan verbeterd worden?
Mijn verstand van classes is nog licht beperkt, dus hier heb ik alleen basis elementen in gebruik.
Daarvoor dient het forum!
Daar kan je vragen stellen.
Hier is de bedoeling dat je werkende,veilige,goede scripts plaatst die nog niet in de bibliotheek zitten. Zodat anderen (beginners?) deze kunnen gebruiken of van kunnen leren. Als je hier dus verkeerde of scripts die niet af zijn plaatst zorg je er dus ook voor dat ze het verkeerd aanleren.
Probeer wat meer met veilige OOP functies te gaan werken.
Voornamelijk de public, private, protected functies.
Op deze site vind ik hier niet echt veel over.
Miss. dat deze link je wat meer op weg kan helpen.
Echter is php 5 wel aan te raden!
Succes!
Voornamelijk de public, private, protected functies.
Op deze site vind ik hier niet echt veel over.
Miss. dat deze link je wat meer op weg kan helpen.
Echter is php 5 wel aan te raden!
Succes!
Toevoegend aan al het andere kritiek:
Waarom alles in 1 classe?
Ik zou 1 classe doen voor het inloggen (die vergelijkt de login gegevens uit het form met de database).
En verder nog 1 classe die de inlogsessie representateerd. (Sessie of Auth ofzo)
Met het opsplitsen in deze twee classes maak je het geheel flexibeler. Nu log je in via een database, later wil je misschien op een andere manier gaan inloggen (met textbestanden (niet doen hoor!) of iets dergelijks).
Dan hoef je niets aan je sessies en cookies te veranderen. Alleen de inlog class..
Waarom alles in 1 classe?
Ik zou 1 classe doen voor het inloggen (die vergelijkt de login gegevens uit het form met de database).
En verder nog 1 classe die de inlogsessie representateerd. (Sessie of Auth ofzo)
Met het opsplitsen in deze twee classes maak je het geheel flexibeler. Nu log je in via een database, later wil je misschien op een andere manier gaan inloggen (met textbestanden (niet doen hoor!) of iets dergelijks).
Dan hoef je niets aan je sessies en cookies te veranderen. Alleen de inlog class..
In echt OOP is het al veel meer...
cookie en session of post vars zijn onderdelen van het request wat de user doet.
zijn immers allemaal externe vars die verzocht worden.
De eventuele database gegevens behoren tot een bepaald model.
Een opgeslagen data model dus.
Die ga je dan dus vergelijken via een mapper.
Die de bevoegtheid heeft om het data model en het request te vergelijken.
In OOP hebben objecten immers hun eigen verantwoordelijheid en domein toch?!
Een login is wellicht niet het simpelste realiseerbaarste in OOP. Zeker niet als je hier rechten en roles en groepen aan gaat hangen zelfs wellicht met een captcha e.d.
Kan wel, maar dan worden het al een hoop items die je nodig hebt.
cookie en session of post vars zijn onderdelen van het request wat de user doet.
zijn immers allemaal externe vars die verzocht worden.
De eventuele database gegevens behoren tot een bepaald model.
Een opgeslagen data model dus.
Die ga je dan dus vergelijken via een mapper.
Die de bevoegtheid heeft om het data model en het request te vergelijken.
In OOP hebben objecten immers hun eigen verantwoordelijheid en domein toch?!
Een login is wellicht niet het simpelste realiseerbaarste in OOP. Zeker niet als je hier rechten en roles en groepen aan gaat hangen zelfs wellicht met een captcha e.d.
Kan wel, maar dan worden het al een hoop items die je nodig hebt.
Waarom blijft dit script hier staan???
Hiervoor is de script library toch helemaal niet bedoeld?
Daarvoor dient het forum!
Daar kan je vragen stellen over je scripts.
Hier is de bedoeling dat je werkende,veilige,goede scripts plaatst die nog niet in de bibliotheek zitten. Zodat anderen (beginners?) deze kunnen gebruiken of van kunnen leren. Als je hier dus verkeerde of scripts die niet af zijn plaatst zorg je er dus ook voor dat ze het verkeerd aanleren.
Hiervoor is de script library toch helemaal niet bedoeld?
Quote:
Deze class heb ik gemaakt met beperkte kennis van classes, en deze plaats ik hier voor jullie, en om deze te laten controleren.
Zit deze class goed in elkaar?
En wat kan eraan verbeterd worden?
Mijn verstand van classes is nog licht beperkt, dus hier heb ik alleen basis elementen in gebruik.
Zit deze class goed in elkaar?
En wat kan eraan verbeterd worden?
Mijn verstand van classes is nog licht beperkt, dus hier heb ik alleen basis elementen in gebruik.
Daarvoor dient het forum!
Daar kan je vragen stellen over je scripts.
Hier is de bedoeling dat je werkende,veilige,goede scripts plaatst die nog niet in de bibliotheek zitten. Zodat anderen (beginners?) deze kunnen gebruiken of van kunnen leren. Als je hier dus verkeerde of scripts die niet af zijn plaatst zorg je er dus ook voor dat ze het verkeerd aanleren.
Om te reageren heb je een account nodig en je moet ingelogd zijn.
Inhoudsopgave
Labels
- Geen tags toegevoegd.
PHP hulp
0 seconden vanaf nu