Ik heb een probleem met strtotime, ik krijg niet bij mijn unix timestamp 600 seconden erbij.. Ik heb het opgezocht maar die oplossingen werken ook niet. Hopelijk hebben jullie een oplossing.
$result = $link->query("SELECT * FROM `foute_login` WHERE `ip`='$ip' ORDER BY `id` DESC LIMIT 1");
$row = $result->fetch_assoc();
$datum = strtotime('+600 seconds', $row['datum']);
if(strtotime('UTC') >= $datum) {
echo '0.U heeft te veel foute pogingen gedaan<br> <a style="cursor: pointer;" data-toggle="modal" data-target="#myModal2">Meer informatie.</a>';
exit();
} else {
$result = $link->query("DELETE FROM `foute_login` WHERE `ip`='$ip'");
if (FALSE === $result) {
echo "0.Er is een fout opgetreden.";
}
}
in de database is het laatste id: 1485043957
[size=xsmall]Toevoeging op 22/01/2017 00:16:46:[/size]
SELECT COUNT(*)
FROM foute_login
WHERE ip = $ip
AND datum > DATE_SUB(UTC_TIMESTAMP(), INTERVAL 10 MINUTE)
Dit geeft je een telling van het aantal foute logins vanaf 1 IP-adres in de laatste 10 minuten. Dat is eigenlijk het enige dat je nodig hebt; alle datumvergelijkingen in PHP kun je overboord gooien. (Het werkt overigens alleen als de kolom die jij 'datum' hebt genoemd, niet alleen een datum maar ook een tijd bevat, maar dat is logisch.)
Het werkt overigens alleen als de kolom die jij 'datum' hebt genoemd, niet alleen een datum maar ook een tijd bevat, maar dat is logisch.
Er valt misschien ook iets te zeggen voor het volgende: zorg dat je één bron hebt voor het bepalen en opslaan van (die) tijd. Laat dit of PHP zijn, of MySQL, maar niet een mengvorm van beide, want het is niet gegarandeerd (bij mijn weten?) dat de klokken van beide (altijd) gelijk lopen. Als je dit niet doet ben je mogelijk met twee maten aan het rekenen wat bij hoge precisie (seconden, minuten) voor problemen kan zorgen.
Als dit niet uitmaakt ben ik benieuwd wat dan de bepalende factoren precies zijn en zelfs dan lijkt het mij vanuit oogpunt van ondubbelzinnigheid verstandig om één standaard aan te houden.
ik heb ooit last gehad van die situatie: om 0:00 startte een cronjob die iets deed met de records van "gisteren".
Helaas liep de klok van de server waarop de database stond een paar minuten achter, zodat "gisteren" in de beleving van mysql dus nog een dag eerder was, aangezien het nog net geen 1200 's nachts was.
Beetje systeembeheerder heeft daar trouwens geen last van...
