Wachtwoord vergeten
Maar nou zit ik even te denken wat handig en veilig is.
IDEE 1
- vul je emailadres in, controle of deze bestaat
- zo ja, een nieuw wachtwoord wordt opgeslagen in 'wachtwoordnw' en verstuurd per mail naar de gebruiker.
- nu kan de gebruiker inloggen met het nieuwe wachtwoord of de mail negeren en gewoon inloggen met zijn huidige wachtwoord.
- als je inlogt wordt er gecontroleerd of veld 'wachtwoordnw' is ingevuld, zo ja, wordt het ingevulde wachtwoord met beide velden gecontroleerd (om te voorkomen dat je geen wachtwoord hoeft in te vullen omdat het veld leeg is)
- als je bent ingelogd met het nieuwe wachtwoord, wordt je gestuurd naar een pagina om je wachtwoord te wijzigen, het veld wachtwoordnw wordt weer leeg gemaakt.
IDEE 2
- Vul je emailadres in, als deze bestaat wordt er een verificatiecode opgeslagen in de database
- er wordt een mail gestuurd met een linkje met de verificatiecode erin, als je deze opent wordt je ingelogd en je kunt een nieuw wachtwoord invullen
- als je niks doet kun je gewoon met je eigen wachtwoord inloggen.
- bij inloggen wordt het verificatiecode veld weer leeg gemaakt.
Beide ideeën lijken mij niet erg veilig en handig. Al zal ik eerder voor IDEE 2 gaan.
Sowieso wil ik dat een gebruiker niet verplicht is een nieuw wachtwoord in te moeten vullen omdat één of andere grapjas zijn wachtwoord heeft opgevraagd.
Wat vinden jullie van de ideeën en hoe zou jullie het oplossen?
Bvd!
p.s.: ik vraag niet om code of linkjes e.d., alleen ideeën.
Gene die het wachtwoord opvraagt, moet het zelfde IP hebben als de gene die op de link klinkt? Dit is wel erg irritant als je daartussen in van IP adres wisselt terwijl het wel gewoon de zelfde gebruiker is.
Na 12uur verwijderen is opzich wel een idee. Moet ik hier wel weer een cronjob o.i.d. voor laten lopen.
Je kunt ook iedere keer dat iemand (ongeacht wie) inlogt, een subscript laten kijken of er nog 'overdatum'-activatiecodes staan en deze laten verwijderen. Kost op een normale site nauwelijks tijd.
Op IP lijkt me lastig met veranderend IP.
Tobias Witmer op 15/04/2011 13:53:33:
Cronjob is op zich niet nodig.
Je kunt ook iedere keer dat iemand (ongeacht wie) inlogt, een subscript laten kijken of er nog 'overdatum'-activatiecodes staan en deze laten verwijderen. Kost op een normale site nauwelijks tijd.
Op IP lijkt me lastig met veranderend IP.
Je kunt ook iedere keer dat iemand (ongeacht wie) inlogt, een subscript laten kijken of er nog 'overdatum'-activatiecodes staan en deze laten verwijderen. Kost op een normale site nauwelijks tijd.
Op IP lijkt me lastig met veranderend IP.
Kan inderdaad, maar kost meer dan 1x per dag een cronjob laten starten.
IP lijkt me inderdaad ook niet de ideale oplossing.
Andere ideeën of zou jij idee 1 of idee 2 aanraden?
Cronjobs zijn volgens mij niet nodig, volgens mij is het gewoon op te lossen met de juiste query.
@Karl: Waarom zou je het in een aparte tabel willen? Het is immers nooit meer dan 1 record. Zou je een goede reden kunnen noemen behalve dat 't netter is?
Edit: Site werkt trouwens niet helemaal lekker hier.
Hij bleef een paar keer hangen omdat die w.sharethis.com aan 't laden was en daarom laad die de rest van de site ook maar gewoon niet.
Gewijzigd op 15/04/2011 14:47:37 door Michael -
Tur min op 15/04/2011 14:08:17:
Kan inderdaad, maar kost meer dan 1x per dag een cronjob laten starten.
Er kan op elk moment van de dag een 'wachtwoord vergeten' aanvraag worden gedaan. Dus bij een cronjob die eenmaal per 24 uur draait klopt er van de 'binnen 12 uur' helemaal niets meer. Om dat exact te doen moet je cronjob elke minuut draaien. Dus doe dat maar gewoon even als er iemand inlogt. Even kijken bij wie de 12 uur om zijn.
Tur min op 15/04/2011 14:46:12:
Hij bleef een paar keer hangen omdat die w.sharethis.com aan 't laden was
Adblock installeren en die site blocken. Geen irritatie meer en geen reclame.
- SanThe - op 15/04/2011 16:00:24:
Er kan op elk moment van de dag een 'wachtwoord vergeten' aanvraag worden gedaan. Dus bij een cronjob die eenmaal per 24 uur draait klopt er van de 'binnen 12 uur' helemaal niets meer. Om dat exact te doen moet je cronjob elke minuut draaien. Dus doe dat maar gewoon even als er iemand inlogt. Even kijken bij wie de 12 uur om zijn.
Adblock installeren en die site blocken. Geen irritatie meer en geen reclame.
Tur min op 15/04/2011 14:08:17:
Kan inderdaad, maar kost meer dan 1x per dag een cronjob laten starten.
Er kan op elk moment van de dag een 'wachtwoord vergeten' aanvraag worden gedaan. Dus bij een cronjob die eenmaal per 24 uur draait klopt er van de 'binnen 12 uur' helemaal niets meer. Om dat exact te doen moet je cronjob elke minuut draaien. Dus doe dat maar gewoon even als er iemand inlogt. Even kijken bij wie de 12 uur om zijn.
Tur min op 15/04/2011 14:46:12:
Hij bleef een paar keer hangen omdat die w.sharethis.com aan 't laden was
Adblock installeren en die site blocken. Geen irritatie meer en geen reclame.
Om de minuut vind ik sowieso dan weer onzin. Dan om 't uur of zo.
Ik doe 't wel op 't moment dat iemand inlogt. dan gelijk alle verificatiecodes ouder dan 12uur wissen + de verificatiecode van de ingelogde gebruiker.
Als verder niemand meer op- of aanmerkingen heeft zal ik 'idee 2' icm de wijzigingen die zijn aangegeven.
AdblockPlus heb ik sowieso al jaren anders wordt je helemaal gek op internet.
Ik zal die sharethis onzin er is aan toevoegen.
EDIT: sharethis staat er blijkbaar wel tussen
||l.sharethis.com^ Ingeschakeld 487 treffers
Ik heb ||w.sharethis.com^ er aan toegevoegd, en nou werkt t weer een stuk sneller.
Gewijzigd op 15/04/2011 16:27:53 door Michael -
Tur min op 15/04/2011 14:46:12:
(...)
@Karl: Waarom zou je het in een aparte tabel willen? Het is immers nooit meer dan 1 record. Zou je een goede reden kunnen noemen behalve dat 't netter is?
(...)
@Karl: Waarom zou je het in een aparte tabel willen? Het is immers nooit meer dan 1 record. Zou je een goede reden kunnen noemen behalve dat 't netter is?
(...)
Het is netter en handiger. Je hoeft geen cronjobs meer te draaien, je kunt er statistiek op toepassen enzovoort.
Sowieso geeft de netheid al de doorslag.
Karl Karl op 15/04/2011 16:58:11:
Het is netter en handiger. Je hoeft geen cronjobs meer te draaien, je kunt er statistiek op toepassen enzovoort.
Sowieso geeft de netheid al de doorslag.
Tur min op 15/04/2011 14:46:12:
(...)
@Karl: Waarom zou je het in een aparte tabel willen? Het is immers nooit meer dan 1 record. Zou je een goede reden kunnen noemen behalve dat 't netter is?
(...)
@Karl: Waarom zou je het in een aparte tabel willen? Het is immers nooit meer dan 1 record. Zou je een goede reden kunnen noemen behalve dat 't netter is?
(...)
Het is netter en handiger. Je hoeft geen cronjobs meer te draaien, je kunt er statistiek op toepassen enzovoort.
Sowieso geeft de netheid al de doorslag.
Hm, naar mijn idee is het niet praktisch.
Sowieso is het maar 1 record dus kun je ook bij de gebruiker als veld toevoegen en die updaten.
Als je het in een aparte tabel wil doen, moet je het emailadres gebruiken om toch weer te linken met de gebruikers tabel.
Tot zover zie ik nog geen voordelen en voeg zolang dan ook gewoon een veld toe aan gebruikers waarin een verificatiecode komt. Mocht je nog iets hebben waarmee je me overtuigt hoor ik 't graag.
Je slaat het per keer per aanvraag op.
Ip, wie, wat de code is, datum tijd.
Gewoon de wachtwoord vergeten datum/tijd met de huidige datum/tijd vergelijken en zodoende aanvraag oplossen of niet. Dit gaat eigenlijk alleen maar lekker als je een aparte tabel hebt. Ooit van database-optimalisatie gehoord?
Karl Karl op 15/04/2011 17:07:23:
Hoezo maar 1 record?
Je slaat het per keer per aanvraag op.
Ip, wie, wat de code is, datum tijd.
Je slaat het per keer per aanvraag op.
Ip, wie, wat de code is, datum tijd.
Ik bedoel je hebt 1 record per gebruiker. Dus ik vat nog niet helemaal wat er het voordeel van zou zijn.
Als de gebruiker nu 2 maal zijn wachtwoord zou opvragen dan krijg je 2 records en zou je dus met 2 activeringscodes kunnen inloggen.
Bram Boos op 15/04/2011 18:50:43:
Wat Karl zegt en een cron heb je voor dit echt niet nodig.
Gewoon de wachtwoord vergeten datum/tijd met de huidige datum/tijd vergelijken en zodoende aanvraag oplossen of niet. Dit gaat eigenlijk alleen maar lekker als je een aparte tabel hebt. Ooit van database-optimalisatie gehoord?
Gewoon de wachtwoord vergeten datum/tijd met de huidige datum/tijd vergelijken en zodoende aanvraag oplossen of niet. Dit gaat eigenlijk alleen maar lekker als je een aparte tabel hebt. Ooit van database-optimalisatie gehoord?
Zeker ken ik database-optimalisatie, maar waarom dat hierop moet worden toegepast is mij onduidelijk. Zoals ik al zei heb je per gebruiker maar 1 record nodig.