Ik heb bij de inlogpagina de mogelijkheid om een vergeten wachtwoord te resetten.
Dat geldt ook bij een vergeten gebruikersnaam.
Nu heb ik een uniek lidnummer.
Ik zou in de welkomstmail dit nummer eenmalig kunnen vermelden.
Daarmee zou bij het kwijtraken van zowel ww en gebruikersnaam eventueel
ingelogd kunnen worden (wachtwoord en gebruikersnaam resetten ?)
Is dat een redelijke mogelijkheid?
Of de gebruikersnaam vermelden?
Het emailadres is natuurlijk ook uniek.
Ik werk liever niet (meer) met persoonlijke vragen....
Of gewoon berichtje naar de beheerder ?
Je hebt gelijk Arien... Maar het een hoeft het ander niet uit te sluiten..
Ik sla het IP al op.
Je kunt ook door de aanvraag via email achterhalen of het IP overeenkomt met hetgene die bij de email hoort.
Dan kun je direct de aanvraag blokkeren.
En de eigenaar van de email waarschuwen dat iemand met ander ip adres een melding wilde doen...
Wel leuk om eens uit te proberen...
Hoewel IP ook te omzeilen is natuurlijk.
Maar als optie wel leuk.
Jij had bij het inloggen toch ook eens controle op IP als optie toegevoegd?
Ik heb dat nu ook als extra (aanvinken).
Moet ik nu bij aanvinken op de thuisip alle inlogpogingen elders direct blokketen ?
Want nu heb ik het nog dat wanneer elders ingelogd wordt de keuze er weer is om aan te vinken.
IP-adressen zijn niet persoonlijk, en kunnen ook veranderen. Als ik via 4G aan het internetten ben dan heb ik ook steeds een ander IP-adres.
Ik had in een vroeger inlog-systeem (inmiddels offline) een optie ingebouwd om een inlog-sessie te locken op IP. Dit hield in dat de gemaakte inlogsessie alleen maar werkte op het IP-adres waarmee je inlogt. Hiermee werden er geen andere sessies zomaar afgesloten, en het moest session-hijacking voorkomen. Het hele inlog-systeem werkte niet op PHP-sessions, maar op cookies met een unieke hash en de userID.
Het voordeel was dat de gebruiker eenvoudig controle had op zijn openstaande inlog-sessies.
Ik heb/had het nu zo dat bij elke wijziging mbt inloggen (vergeten ww, veranderen ww, vergeten gebruikersnaam, veranderen gebruikersnaam) de unieke hash veranderd wordt bij de sessie. De referentie sessie id blijft.. Deze komen overeen met de 2 cookies. Die cookies gebruik ik als herkenning op de openbare site. Er zijn handelingen zoals reageren, die alleen door leden gedaan mogen worden. Bezoekers kunnen wel alle info bekijken, maar geen acties.
Bedankt voor de info...
In het ene cookie staat een gecodeerd lidnr. in het andere de variabele value.
Ik moet weer even terug in de tijd hoe ik dit gedaan heb.
Want aan een waarde (de variabele) heb ik toch ook genoeg?
Die moeten samen dus kloppen met de opgeslagen waarde voordat er toegang is tot het openbare gedeelte met de reactie mogelijkheid.
Mocht een cookie niet meer aanwezig zijn (pc opgeschoond), dan moet men weer eerst 1 keer inloggen om weer een cookie te produceren.
Is dat zo? Hoe verloopt de route van e-mail dan vanaf het moment dat er een e-mail verzonden wordt vanaf een website.... aangezien je zegt dat het geen DNS verwijzing betreft?
Edit: een MX record is niet noodzakelijk, dit kan ook via de A record, dus dit zou ook via de AAAA record kunnen verlopen, wat dus inhoud dat een tweede VPS ingezet kan worden, dus 1 domein, 2 stromen, 2 VPSen, dus niet meer uniek.
Uiteraard is dat zo, een dom geconfigureerde DNS doet daar niets aan af. E-mail gaat maar 1 kant op, ongeacht of je meerdere A records inzet of AAAA records toevoegt. Het eindpunt wordt wat onvoorspelbaarder, maar dat is niet de schuld van het adres op zichzelf.
Mee eens; dus in hoeverre is het e-mailadres uniek?
Met de nadruk op "uniek".
Natuurlijk snap ik dat "[email protected]" uniek is in zekere zin, er is er namelijk maar 1 van, maar in de praktijk zouden dit er dus best "meerdere" [email protected] kunnen zijn, verdeelt over meerdere mailservers, afhankelijk van de route van de ontvanger.
Ik vind daarom ook dat "uniek", niet de lading denkt, mede omdat het op diverse manieren afgevangen kan worden, zonder de daadwerkelijke gebruiker te verifieren.
Het is een aanname; dat de route klopt + de SPF / PTR records etc allemaal ingesteld zijn om maar te verifieren dat het betreffende domein ook daadwerkelijk op die computer afgehandeld word.
Maar vanaf het punt dat een e-mail wordt verzonden vanaf een webserver --> lets say: $mail->send(); dat al die checks niet plaats vinden, dus de eindgebruiker is niet "gegarandeerd" als je het mij vraagt.
